Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Filetransfer API
Hi Pascal,

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?

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 type.

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 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.

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 requirements.

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 interfaces.


- 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.

Yes, good idea...will do.


- 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.

I'm going to remove this comment/note.



- 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.

- Should not IIncomingFileTransferReceiveStartEvent 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 IIncomingFileTransferReceiveStartEvent extend 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.

Scott


PaScaL 


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top