Re: [ecf-dev] No Mon 25th conference call, and ECF API work focus propos

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Remy,

Remy Suen wrote:
> Hi Scott,
>
> On 9/26/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> > 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 
>
> So I'm guessing that getBytesReceived() and getBytesSent() is going to
> be constantly updated as the transfer moves along? If the underlying
> protocol/implementation doesn't support the send/receive events, is it
> just going to return 0 or -1?

I modified the javadocs to say that if the underlying provider does not 
support the getBytesReceived/getBytesSent that it will return -1.

> Also, I noticed that the class level javadoc of the
> IIncomingFileTransferRecieveCompleteEvent interface needs to be
> updated since it's currently the same
> IIncomingFileTransferReceiveDataEvent.

You are right.  The *CompleteEvents are superfluous so I removed them.  
Rather than have separate event classes/interfaces when complete, when 
*Data events are received, the receiver can do the following to 
determine if the transfer is complete:

IIncomingFileTransfer ift = event.getSource();
if (ift.isDone() {
...
}

This way there will be less logic for the event handler.

Thanks,

Scott



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