Hi Pascal and all,|
Pascal Rapicault wrote:
Lately I have been using the file
API. With the examples available I was able to get up and running
This is cool.
Now I have a few questions/remarks
- Is there a way to know which
There is now an API on org.eclipse.ecf.core.identity.Namespace (which
is available via
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
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
- To make the API complete around
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
a callback (an authentication event) asking for username/pwd. As for
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
- I found myself having to hardcode
the constant for the generic container and I also saw it in other
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
note: "This method is not intended to be called by clients".
I think that leaving the collection of those objects to the GC is
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
could beneficiate from having a receive method that takes an
(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.