Hi Pascal and all,
Pascal Rapicault wrote:
Hi,
Lately I have been using the file
transfer
API. With the examples available I was able to get up and running
quickly.
This is cool.
Now I have a few questions/remarks
on
the APIs.
- Is there a way to know which
transports
are supported?
There is now an API on org.eclipse.ecf.core.identity.Namespace (which
is available via
org.eclipse.ecf.filetransfer.IRetrieveFileTransferContainerAdapter.getRetrieveNamespace()).
public String [] getSupportedSchemes().
The intention is that for any/all ECF APIs that implement their own
Namespace, that they can use this to publish supported
schemes/transports (e.g. "http", "https", "ftp", "bittorrent", etc).
That said, I'm struggling a little bit right now to implement the
FileTransferNamespace for the file transfer provider. The reason, is
that we currently have the Apache httpclient 3.0.1 to implement http,
and https...simple enough to just return "http" and "https". But I
also use the java.net.URLConnection class to expose all other protocols
supported by the underlying VM (e.g. in Sun's it's "ftp" and "file" and
others) and would like to discover/expose *all* schemes made available
via the java.net.URLStreamHandlerFactory (in fact it's via the
URLStreamHandlerService in OSGi/Eclipse so that schemes/protocols can
come and go as bundles are added/removed). The
URLStreamHandlerService doesn't seem to expose such a protocol query
interface.
I'm investigating as to whether the URLStreamHandlerService provides
notification of scheme registration events. If it does, I suppose I
can setup a listener for those and keep them stored away somewhere.
If others have ideas about how to handle this (other than just
returning a hard-coded array of schemes). Please let me and everyone
know.
- To make the API complete around
transfer,
I think it would be great to be able to have support for authentication
and proxy. For example, the authentication support could be as simple
as
a callback (an authentication event) asking for username/pwd. As for
the
proxy I'm not sure what shape it should have.
The file transfer API now has both a callback structure for
authentication (similar to JAAS, but without requiring JAAS). And it
has a proxy interface as well. See
IRetrieveFileTransferContainerAdapter.setConnectContextForAuthentication
and .setProxy.
- I found myself having to hardcode
the constant for the generic container and I also saw it in other
places.
Given that it is the generic/default container, I suggest the addition
of a constant in one of the interface.
OK, will be added.
- IContainer.dispose() has the
following
note: "This method is not intended to be called by clients".
I think that leaving the collection of those objects to the GC is
"dangerous"
as we never know when it will run. Moreover there are some cases where
you know exactly when you are done with the object. So I would suggest
to either remove the note or add another method that clients can call.
Note has been removed.
- The interface
IIncomingFileTransferReceiveStartEvent
could beneficiate from having a receive method that takes an
OutputStream
(see attached patch). For completeness a similar method should probably
be added to the outgoing API and also on IFileTransferRequestEvent.
Patch applied. Now has method.
Thanks,
Scott
|