Re: [ecf-dev] Filetransfer API

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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