The results of your email command are provided below. Attached is your
original message.
- Unprocessed:
I prefer the conference calls early in the evenings when I get home =20
i.e. 18:00 - 21:00 p.m. everyday except Tuesdays.
Regards,
Roland.
Quoting ecf-dev-request@xxxxxxxxxxx:
> Send ecf-dev mailing list submissions to
> =09ecf-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> =09https://dev.eclipse.org/mailman/listinfo/ecf-dev
> or, via email, send a message with subject or body 'help' to
> =09ecf-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
> =09ecf-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ecf-dev digest..."
>
>
- Ignored:
> Today's Topics:
>
> 1. Re: Bi-weekly conference call date/time (Scott Lewis)
> 2. Re: Re: Bi-weekly conference call date/time (Ted Kubaska)
> 3. Re: Re: Bi-weekly conference call date/time
> (Markus Alexander Kuppe)
> 4. Credentials and proxy API for file retrieval (Henrich Kraemer)
> 5. Re: Credentials and proxy API for file retrieval (Scott Lewis)
> 6. RE: Re: Bi-weekly conference call date/time
> (Rellermeyer Jan Simon)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Sep 2008 10:11:17 -0700
> From: Scott Lewis <slewis@xxxxxxxxxxxxx>
> Subject: [ecf-dev] Re: Bi-weekly conference call date/time
> To: "Eclipse Communication Framework (ECF) developer mailing list."
> =09<ecf-dev@xxxxxxxxxxx>
> Message-ID: <48D7D1B5.8070504@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>
> Hi Folks,
>
> OK, how about Tuesdays at 1400 UTC (7am pacific time, 10am eastern, and
> 4pm Berlin)
>
>
http://www.timeanddate.com/worldclock/fixedtime.html?year=3D2008&month=3D9=
&day=3D23&hour=3D14&min=3D00&sec=3D0
>
> Can a plurality of people make this every two weeks?
>
> Please respond to the list as quickly as possible with +1 or -1.
>
> Thanks,
>
> Scott
>
>
> Mustafa K. Isik wrote:
>>> Mustafa K. Isik wrote:
>>>
>>>> I would suggest Fridays at 1500/3PM UTC (which translates to =20
>>>> 1700/5PM Berlin).
>>>>
>> On Fri, Sep 19, 2008 at 10:17, Markus Alexande Kuppe
>> <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:
>>
>>> Please any other day but Friday. People tend to balance out
overtime on
>>> Fridays.
>>>
>>
>> In that case, I'd suggest either Mondays or Tuesdays.
>>
>>
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 22 Sep 2008 11:54:58 -0700
> From: "Ted Kubaska" <ted.kubaska@xxxxxxxxx>
> Subject: Re: [ecf-dev] Re: Bi-weekly conference call date/time
> To: "Eclipse Communication Framework (ECF) developer mailing list."
> =09<ecf-dev@xxxxxxxxxxx>
> Message-ID:
> =09<a9a5a160809221154g1c3f349ai1e2ae49c6dff1355@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=3DISO-8859-1
>
> +1 -ted
>
> On Mon, Sep 22, 2008 at 10:11 AM, Scott Lewis
<slewis@xxxxxxxxxxxxx> wrote=
:
>> Hi Folks,
>>
>> OK, how about Tuesdays at 1400 UTC (7am pacific time, 10am
eastern, and 4=
pm
>> Berlin)
>>
>>
http://www.timeanddate.com/worldclock/fixedtime.html?year=3D2008&month=3D=
9&day=3D23&hour=3D14&min=3D00&sec=3D0
>>
>> Can a plurality of people make this every two weeks?
>> Please respond to the list as quickly as possible with +1 or -1.
>>
>> Thanks,
>>
>> Scott
>>
>>
>> Mustafa K. Isik wrote:
>>>>
>>>> Mustafa K. Isik wrote:
>>>>
>>>>>
>>>>> I would suggest Fridays at 1500/3PM UTC (which translates
to 1700/5PM
>>>>> Berlin).
>>>>>
>>>
>>> On Fri, Sep 19, 2008 at 10:17, Markus Alexande Kuppe
>>> <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:
>>>
>>>>
>>>> Please any other day but Friday. People tend to balance out
overtime on
>>>> Fridays.
>>>>
>>>
>>> In that case, I'd suggest either Mondays or Tuesdays.
>>>
>>>
>>>
>>
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>
>
>
>
> --
> -Ted
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 22 Sep 2008 21:47:57 +0200
> From: Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
> Subject: Re: [ecf-dev] Re: Bi-weekly conference call date/time
> To: "Eclipse Communication Framework (ECF) developer mailing list."
> =09<ecf-dev@xxxxxxxxxxx>
> Message-ID: <48D7F66D.9090200@xxxxxxxxxxx>
> Content-Type: text/plain; charset=3DISO-8859-1
>
> Scott Lewis wrote:
>> Hi Folks,
>>
>> OK, how about Tuesdays at 1400 UTC (7am pacific time, 10am
eastern, and
>> 4pm Berlin)
>>
>>
http://www.timeanddate.com/worldclock/fixedtime.html?year=3D2008&month=3D=
9&day=3D23&hour=3D14&min=3D00&sec=3D0
>>
>>
>> Can a plurality of people make this every two weeks?
>> Please respond to the list as quickly as possible with +1 or -1.
>
> +1
>
> Cheers
> Markus
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 22 Sep 2008 14:24:23 -0700
> From: Henrich Kraemer <henrich.kraemer@xxxxxxxxxx>
> Subject: [ecf-dev] Credentials and proxy API for file retrieval
> To: ecf-dev@xxxxxxxxxxx
> Message-ID:
>
=09<OFC407C137.278C743D-ON882574CC.006FB16E-882574CC.007596FD@xxxxxxxxxx>
> Content-Type: text/plain; charset=3D"us-ascii"
>
>
>
> I am trying to understand how IRetrieveFileTransferContainerAdapter and
> IRetrieveFileTransfer work in particular with respect to
authentication fo=
r
> both proxy and the targeted server.
>
> IRetrieveFileTransfer extends
IRetrieveFileTransferContainerAdapter and ca=
n
> be created via IRetrieveFileTransferFactory which is
registered as an OSGI
> service. Below are some snippets from the JavaDocs:
>
> The IRetrieveFileTransferContainerAdapter methods
> setConnectContextForAuthentication(IConnectContext)
> * This method should be called with a non-null connectContext
in order to
> allow
> * authentication to occur during call to
>
> and setProxy(Proxy).
> * This method should be called with a non-null proxy to allow the given
> proxy to
> * be used in subsequent calls to
>
> It seems ECFs' API is similar to Apache HttpClient version 4
with respect
> to authentication, where the caller is responsible to manage
credentials.
> See my related question to the HttpClient mailing list with Subject
> "Potential account lockouts when using authentication using
concurrent htt=
p
> requests"
>
http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/200809.mbox/%=
3COFDC66AEAE.C8077D2D-ON882574C6.00726684-882574C6.0075A515@xxxxxxxxxx%3E
>
> It appears different credentials can be set independently for different
> IRetrieveFileTransfer or IRetrieveFileTransferContainerAdapter
instances.
> If the ECF API caller is responsible for managing credentials, I would
> expect that a lack of credentials would cause the retrieval to
fail (if
> authentication is needed by the server). Similar if bad
credentials such a=
s
> a bad password are provided. The ECF retrieval should not
cause a dialog t=
o
> popup in these cases. Instead when a retrieval fails the
caller can decide
> whether to prompt the user an retry the retrieval on the same
> IRetrieveFileTransfer (or adapter).
>
> Main question: Is this describing the API correctly?
>
> Additional questions:
> Q1: How can the caller determine that authentication failed?
>
> Q2a: How can the caller determine for which authentication
scope (AuthScop=
e
> in HttpClient land) the credentials were requested for (this
may include a
> realm string)? (RFC 2617 support)
> Q2b: How to know whether proxy credentials or target authorization and
> credentials are needed?
>
> Q3: How can authentication state be carried along?
> Authentication headers will need information from previous
requests. Unles=
s
> there is a mechanism to carry this state forward from a
previously failed
> request, the previous request/response must be redone which should be
> avoided for efficiency reasons. Perhaps a general mechanism to keep
> conversational state would make sense.
>
> Q4: The need for Authentication can be influenced by the presence of
> cookies. How are cookies managed?
>
> Q5: HttpClient 3 and 4 provide a great deal of connection
management logic=
.
> Typically one would want to use the same connection manager across
> different retrievals. How can ECF take advantage of this?
>
> Q6: An alternative to having the ECF consumer deal with
authentication, EC=
F
> could potentially be responsible for managing this.
Credentials and proxy
> info would not have to be passed in at all and ECF would do 'the right
> thing'. However in this case some API would presumably be
needed to clear
> (some) credentials, cookies, close open connections etc.
>
> Thanks much,
>
> Henrich
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: =20
>
https://dev.eclipse.org/mailman/private/ecf-dev/attachments/20080922/85b66=
3f0/attachment.html
>
> ------------------------------
>
> Message: 5
> Date: Mon, 22 Sep 2008 15:01:06 -0700
> From: Scott Lewis <slewis@xxxxxxxxxxxxx>
> Subject: Re: [ecf-dev] Credentials and proxy API for file retrieval
> To: "Eclipse Communication Framework (ECF) developer mailing list."
> =09<ecf-dev@xxxxxxxxxxx>
> Message-ID: <48D815A2.4060800@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>
> Hi Henrich,
>
> Henrich Kraemer wrote:
>>
>> I am trying to understand how IRetrieveFileTransferContainerAdapter
>> and IRetrieveFileTransfer work in particular with respect to
>> authentication for both proxy and the targeted server.
>>
>> IRetrieveFileTransfer extends IRetrieveFileTransferContainerAdapter
>> and can be created via IRetrieveFileTransferFactory which is
>> registered as an OSGI service. Below are some snippets from
the JavaDocs:
>>
>> The IRetrieveFileTransferContainerAdapter methods
>> setConnectContextForAuthentication(IConnectContext)
>> * This method should be called with a non-null connectContext in order
>> to allow
>> * authentication to occur during call to
>>
>> and setProxy(Proxy).
>> * This method should be called with a non-null proxy to allow the
>> given proxy to
>> * be used in subsequent calls to
>>
>> It seems ECFs' API is similar to Apache HttpClient version 4 with
>> respect to authentication, where the caller is responsible to manage
>> credentials.
>> See my related question to the HttpClient mailing list with Subject
>> "Potential account lockouts when using authentication using concurrent
>> http requests"
>>
http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/200809.mbox/=
%3COFDC66AEAE.C8077D2D-ON882574C6.00726684-882574C6.0075A515@xxxxxxxxxx%3E
>>
>> It appears different credentials can be set independently for
>> different IRetrieveFileTransfer or
>> IRetrieveFileTransferContainerAdapter instances. If the ECF API caller
>> is responsible for managing credentials, I would expect that a lack of
>> credentials would cause the retrieval to fail (if authentication is
>> needed by the server). Similar if bad credentials such as a bad
>> password are provided. The ECF retrieval should not cause a dialog to
>> popup in these cases. Instead when a retrieval fails the caller can
>> decide whether to prompt the user an retry the retrieval on the same
>> IRetrieveFileTransfer (or adapter).
>>
>> Main question: Is this describing the API correctly?
>>
>
> Yes, in general. The ECF API caller is (currently) responsible for
> managing credentials.
>
>>
>> Additional questions:
>> Q1: How can the caller determine that authentication failed?
>>
>
> If authentication fails (for http) the sendRetrieveRequest should throw
> an Exception. Previous to what's in HEAD (i.e. 3.4.0/ECF 2.0.0), there
> was no easy way to determine the exception/error type. In response to
> this bug 226769, though, we've added a getErrorCode method on the
> exception class. Although there's some desire (on my part as well as
> Pascal's) to define some more structure than int for error code. It
> might make more sense to have an enum that had all the appropriate
> failure codes...including auth failures of course...for file transfer
> (rather than just returning an int).
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D226769
>
>
>>
>> Q2a: How can the caller determine for which authentication scope
>> (AuthScope in HttpClient land) the credentials were requested for
>> (this may include a realm string)? (RFC 2617 support)
>>
>
> One way would be to add an ObjectCallback that exposed the
realm info to
> the callback handler. The existing providers don't do this, but it
> would/could be easily added.
>
>> Q2b: How to know whether proxy credentials or target authorization and
>> credentials are needed?
>>
>
> The setProxy API allows callers to override the Platform proxy API, but
> if the setProxy is *not* used explicitly, the current impl of both
> providers will use the org.eclipse.core.net proxy API (if that
bundle is
> present) to get/use proxy information and proxy credentials.
>
>>
>> Q3: How can authentication state be carried along?
>>
>
> It can/could be done via the Callbacks created by the provider before
> calling the CallbackHandler.handle() method. That being said, we don't
> do this now.
>
>> Authentication headers will need information from previous requests.
>> Unless there is a mechanism to carry this state forward from a
>> previously failed request, the previous request/response must be
>> redone which should be avoided for efficiency reasons. Perhaps a
>> general mechanism to keep conversational state would make sense.
>>
>> Q4: The need for Authentication can be influenced by the presence of
>> cookies. How are cookies managed?
>>
>
> They are not currently managed by the ECF provider code. If a specific
> provider manages them (e.g. httpclient or urlconnection) then
that's how
> they are managed.
>
>>
>> Q5: HttpClient 3 and 4 provide a great deal of connection management
>> logic. Typically one would want to use the same connection manager
>> across different retrievals. How can ECF take advantage of this?
>>
>
> The httpclient provider can/could be modified to use the same
connection
> manager (if I'm understanding correctly).
>
>>
>> Q6: An alternative to having the ECF consumer deal with
>> authentication, ECF could potentially be responsible for managing
>> this. Credentials and proxy info would not have to be passed in at all
>> and ECF would do 'the right thing'.
>>
>
> In the case of proxy info ECF does do 'the right thing'...assuming that
> the right thing is using the platform's net proxy API :).
>
>> However in this case some API would presumably be needed to clear
>> (some) credentials, cookies, close open connections etc.
>>
>
> Yes. For ECF to manage credentials that's agreed...there would be
> additional API (and probably UI also) needed to manage/clear
> credentials, cookies, etc.
>
> Incidently, one of the things that I will likely be looking to add in
> ECF 2.1 is an ECF 'storage' API that uses the Equinox secure
preferences
> API. I have this API running/tested (it's available in
> /cvsroot/technology/org.eclipse.ecf plugins/org.eclipse.ecf.storage
> plugin also a tests/org.eclipse.ecf.tests.storage plugin exists). The
> point of this plugin is to allow ECF IDs (e.g. IFileIDs) to be easily
> stored and retrieved securely (along with arbitrary data...like
> passwords...that need to be stored and associated with IDs/IFileIDs).
> See methods on IIDStore and test code if you are interested.
One of the
> main things that was keeping us back from managing credentials within
> ECF itself was the lack of availability of secure storage in the
> platform. So now that issue is gone...and we have the IIDStore API we
> can/could add credentials management/storage to ECF itself.
>
> Thanks,
>
> Scott
>
>
>>
>> Thanks much,
>>
>> Henrich
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 23 Sep 2008 00:54:28 +0200
> From: "Rellermeyer Jan Simon" <rellermeyer@xxxxxxxxxxx>
> Subject: RE: [ecf-dev] Re: Bi-weekly conference call date/time
> To: "Eclipse Communication Framework (ECF) developer mailing list."
> =09<ecf-dev@xxxxxxxxxxx>
> Message-ID: <050664ACF0ECC04FA9354B92990A97AF010A4DF4@xxxxxxxxxxxxx>
> Content-Type: text/plain;=09charset=3D"iso-8859-1"
>
> +1 for me as well.
>
> ------------------------------------------------------------
> ETH Zurich, MSc Jan S. Rellermeyer,
> Information and Communication Systems Research Group (IKS),
> Department of Computer Science,
> IFW B 47.1, Haldeneggsteig 4, CH-8092 Z=FCrich Tel +41 44 632
30 38, =20
> http://www.iks.inf.ethz.ch
> ------------------------------------------------------------
>
>
>> -----Original Message-----
>> From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Scott Lewis
>> Sent: Montag, 22. September 2008 19:11
>> To: Eclipse Communication Framework (ECF) developer mailing list.
>> Subject: [ecf-dev] Re: Bi-weekly conference call date/time
>>
>> Hi Folks,
>>
>> OK, how about Tuesdays at 1400 UTC (7am pacific time, 10am
eastern, and
>> 4pm Berlin)
>>
>>
http://www.timeanddate.com/worldclock/fixedtime.html?year=3D2008&month=3D=
9&
>> day=3D23&hour=3D14&min=3D00&sec=3D0
>>
>> Can a plurality of people make this every two weeks?
>>
>> Please respond to the list as quickly as possible with +1 or -1.
>>
>> Thanks,
>>
>> Scott
>>
>>
>> Mustafa K. Isik wrote:
>> >> Mustafa K. Isik wrote:
>> >>
>> >>> I would suggest Fridays at 1500/3PM UTC (which translates to
>> 1700/5PM Berlin).
>> >>>
>> > On Fri, Sep 19, 2008 at 10:17, Markus Alexande Kuppe
>> > <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:
>> >
>> >> Please any other day but Friday. People tend to balance
out overtime
>> on
>> >> Fridays.
>> >>
>> >
>> > In that case, I'd suggest either Mondays or Tuesdays.
>> >
>> >
>> >
>>
>> _______________________________________________
>> ecf-dev mailing list
>> ecf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
>
> ------------------------------
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
>
> End of ecf-dev Digest, Vol 38, Issue 14
> ***************************************
>
- Done.
