Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] No Mon 25th conference call, and ECF API work focus proposal
Hi Pierre, Remy and all.

I've checked in a revised version of the filetransfer API (In org.eclipse.ecf.fileshare plugin in org.eclipse.ecf.filetransfer package).

Please see here for javadocs:

http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/filetransfer/package-summary.html

And here's a little message sequence description for a) A sending file to B; b) A retrieving a remote file

Thanksinadvance,

Scott

For A to request *sending* a file to B

0) B has to have previously called IFileTransferContainer.addIncomingFileTransferRequestListener(listener) so that it is ready for incoming file transfer requests
1) A calls IFileTransferContainer.requestOutgoingFileTransfer(B,localFile,listener).  This results in A sending a request message to B.
2) B's listener receives an IFileTransferRequestEvent.  B now has a choice
    a) B can call accept(File) on the IFileTransferRequestEvent.  This results in a response message being sent back to A.  The IIncomingFileTransfer may be inspected by B for progress status
    b) B can call reject() on the IFileTransferRequestEvent.  This results in a response message being sent back to A.
3) A's listener receives a IOutgoingFileTransferResponseEvent.  The methods on this event type allow A to determine whether B accepted
or rejected (by calling IOutgoingFileTransferResponseEvent.requestAccepted).  If the request was accepted then the file transfer will begin immediately and the IOutgoingFileTransfer object (obtained via IOutgoingFileTransferResponseEvent.getSource()) may be inspected by the sender for progress status, etc.  If the request was rejected then the IOutgoingFileTransfer object may be inspected for IOutgoingFileTransfer.getException()-provided details about the rejection.
4) Both A and B may receive instances of IOutgoingFileTransferSendData/IIncomingFileTransferReceiveData events (respectively) as file data is delivered from A (localFileToSend) to B (localFileToSave).  These events may not be delivered if protocol does not support such notifications
5) A will receive IOutgoingFileTransferSendCompleteEvent and B will receive IIncomingFileTransferReceiveCompleteEvent.  At this point the file is either successfully sent/received or there was an exception and

For A to request *retrieving* a file *from* B

1) A calls IFileTransferContainer.requestRetrieveFileTransfer.  Depending upon provider protocol, this could/will result in A sending a request message to B (or multiple B's) to retrieve file identified by URI
2) A's listener receives an IIncomingFileTransferReceiveStart event.  A can then call receive(localFileToSave) to store the received data in the given local file.
3) Depending upon protocol A may receive IIncomingFileTransferReceiveData events as data is received
4) A will receive IIncomingFileTransferReceiveComplete Event indicating successful or unsuccessful file transfer



Pierre-Henry Perret wrote:
Scott,

I dont see the IIncomingFileTransferListener and IOutgoingFileTransferCreateEvent
IIncomingFileTransferListener in the XMPP provider container implementation.



--
Pierre-Henry Perret
Eclipse ECF committer 

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

Back to the top