Re: [ecf-dev] authentication and file transfer API
Remy Suen wrote:
On 12/8/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
As of last night, I have the ECF file transfer API provider implemented
using apache httpclient 3.0.1.
Where can we get the org.apache.commons bundle that
org.eclipse.ecf.provider.filetransfer currently has a Require-Bundle
Bother. I thought org.apache.commons bundle was now part of the
platform distribution. I guess it must have been installed by Mylar
(which I also have installed) and/or WindowBuilder. I suppose for the
time being I'll have to track it down as jar and put in that
provider.filetransfer as jar.
At the moment, I'm inclined to suggest/use 1, as it's already a generic
authentication callback interface (essentially the same as JAAS
authentication). This would mean that the file transfer provider
implementations would have to store the IConnectContext callbacks passed
in via IContainer.connect(), and then use them appropriately when the
sendRetrieveRequest is actually made.
Note that if we go this route (using the IConnectContext for
authentication for both connection-oriented AND connectionless types of
communication), that this can/could be used for authentication for
any/all extension interfaces (file transfer, bb api, as well as
I think option 1 is good enough since it's pretty straightforward and
should not violate the "least surprise" what-not. But will a
getAdapter(Class) problem arise? At the moment if you are using
sharedobject/provider code, it will go through the platform and
retrieve extensions accordingly and do a new
ClassImplementingAdapter() accordingly. In this scenario, how will the
IConnectContext be passed? Or am I missing something here in this
whole adapter/extension pattern?
No...this is a question. I need to think about it a little.