Re: [ecf-dev] Filetransfer API

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Pascal,

Pascal Rapicault wrote:

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

        This is only one part of the information though, no? Or did I miss something? It seems to me that this does not tell me the list of supported "transports".

True...it does not.  This could be added to the meta-information about a container though...and perhaps it should be (e.g. additional...and perhaps optional...info in extension point schema?). 

This information seems to be available form the IRetriveFileTransferContainerAdapter.getNamespace, but this require the container to be created.
        Also the implementation of getSupportedAdapterTypes() seems to be heavy weight since it requests the creation of the instantiator object to be able to answer the getsupportAdapterTypes. In my case it would mean that I would iterate through all of them causing the activation of their respective plugins, whereas the information is obtained from the adaptor manager. Do you expect the impl of this method to be different for each container provider?

Yes.

>>- 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)
        I had missed this. This is good enough.

After thinking about this some, I think overloading IContainer.connect with authentication for file transfer is going to be quite confusing.  Rather than make file transfer authentication implicitly done by the IContainer.connect, I think it's probably going to be better to be explicit about things and add a method to IRetrieveFileTransferContainerAdapter:

    /**
     * Set connect context for authentication upon subsequent {@link #sendRetrieveRequest(IFileID, IFileTransferListener, Map)}.  This
     * method should be called with a valid connectContext parameter in order to allow authentication to occur during
     * call to {@link #sendRetrieveRequest(IFileID, IFileTransferListener, Map)}.
     *
     * @param connectContext the connect context to use for authenticating during subsequent call to {@link #sendRetrieveRequest(IFileID, IFileTransferListener, Map)}.
     * If null, then no authentication will be attempted.
     */
    public void setConnectContextForAuthentication(IConnectContext connectContext);
    

Any further thoughts/comments are appreciated on this...as things can be changed easily at this point.  Last night (Sun) I went back and forth on this and came to the view that it would probably be better to be explicit on the iretrievefiletransfercontaineradapter interface, while using the same basic approach and classes (i.e. using core IConnectContext callbacks).  This rather than overloading the IContainer.connect call (which could get very confusing I think...mixing authentication with connection oriented vs. connectionless protocols).

Also, I'm considering adding a method on IRetrieveFileTransferContainerAdapter to handle specifying proxy information for a given retrievefiletransfercontaineradapter.

Scott