[
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 Remy,
Remy Suen wrote:
I think IFileTransfer's javadoc needs some clarification. isDone()
only returns true if is the transfer is done, but getException() is
only valid if it's true. Of course, there are some cases where
exceptions are not fatal, but one would assume that if an exception
has appeared, the transfer, or the entire connection, has been cut and
is, as a result, (probably) not done.
I've added to the javadocs for IFileTransfer. Please let all know what
you think. The intention is to have the following semantics:
IFileTransfer.isDone() -- Determines whether transfer has completed:
successfully OR unsuccessfully
IFileTransfer.getException() -- Only valid after isDone() returns true
(won't indicate non-fatal exceptions). Returns null if transfer
completed successfully, non-null if there was an exception (and is the
exception in question).
Does this make sense? It isn't etched in stone of course...the
semantics can be changed. One alternative is that isDone() could throw
an Exception if an exception occurred (rather than returning true), but
I'm not sure I like that very much either. There are other alternatives
as well (e.g. using IStatus from the Jobs API).
On another note, I'm having difficulties figuring out where a torrent
file comes into play once again due to this abnormal way of
transferring files. I considered a file URI being used for
sendRetrieveRequest(URI, IFileTransferListener), but that's supposed
to be a remote file, so it's a little unorthodox.
It seems to me that bittorrent should probably have it's own protocol
for the URI...e.g.
URI target = new URI("torrent:///path/to/torrent/file.bt");
ftc.sendRetrieveRequest(target,listener);
What do people think?
Scott
Regards,
Rem
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
