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
It is possible to enumerate all providers via
ContainerFactory.getDefault().getDescriptions(). The returned List has
ContainerTypeDescription instances in it (would be . Also,
ContainerTypeDescription class has a method
String  ContainerTypeDescrption.getSupportedAdapterTypes()
Which asks the provider to report the adapter types (e.g.
IFileTransferContainerAdapter) that are supported by that container
getSupportedAdapterTypes() is brand new as of 0.9.3, so not all
existing providers have full implementations right now (although I'm
pretty sure the generic container does).
- 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.
Yes. we already have a callback structure for the 'IConnectContext'
that is used in
IContainer.connect(ID targetID, IConnectContext connectContext)
Rather than add a separate authentication callback for file transfer
authentication I've been recently thinking the following:
Providers expect clients to call IContainer.connect() with a
connectContext that defines the authentication callbacks *before* one
of the file transfer methods are called that require authentication.
Then providers (once connect is called) can do whatever they want with
the connectContext...e.g. call the callbacks right way (within
connect() implementation), keep a reference to the connectContext
around for later use (i.e. when the first file transfer is intiated,
etc). Then the various extension APIs for ECF (e.g. file transfer,
presence, datashare, bulletin board, etc) can all have a common way
(via IContainer.connect()) to collect and use provider-specific
credentials information for protocol-specific authentication
This is what I've been thinking, and it's all tentative...so please
feel free to comment positively or negatively (anyone). Note that the
IConnectContext authentication callback interfaces are very similar to
the JAAS authentication callbacks...but not actually JAAS
interfaces...only because the CDC 1.0/Foundation 1.0 does not have
these JAAS elements. If they did, we would/will use the JAAS
- 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.
Yes, good idea...will do.
- 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.
I'm going to remove this comment/note.
- 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.
- Should not
be a subclass IIncomingFileTransferEvent?
It would, except for one thing: the IIncomingFileTransferEvent defines
just one method: IIncomingFileTransfer getSource(). For the *first*
event received in response to retrieve request (i.e.
IIncomingFileTransferReceiveStartEvent), the expectation is that only
after successfully calling receive(File) will the event receiver have
access to the IIncomingFileTransfer instance. The receive(File) call
returns IIncomingFileTransfer to convey these semantics.
That being said, it would be possible to have
IIncomingFileTransferEvent, and have getSource() for that event to
return null. But I thought that would probably be more confusing (i.e.
'why does getSource() return null only for the first one?').
Thanks for comments and suggestions. Will also apply patch RE:
OutputStream...thanks for that too.
ecf-dev mailing list