[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Boris,
I see your points. I think you are right about the avoidance of
implementing IFile.
So perhaps an approach that defined a new 'file handle' interface (not
IFile but rather ISharedFile)...that defined the operations that could
be performed on such a file...including sending, getting, from one or
more container participants (e.g. server but not limited to
server...could be peer...). The operations could have variants that are
synchronous (e.g. getContents()), and those that are not (i.e. with
event listener interfaces required).
So how about something along the lines of
ISharedFile.startSend(ID tohosts, ISharedFileSendProgressListener listener);
ISharedFile.startGet(ID fromhost, ISharedFileReceiveProgressListener
listener);
these methods would return immediately, and the listeners would be
notified *asynchronously* of various transfer events during the
operation (i.e. send started, data sent, send completed, etc).
We could also have synchronous variants:
ISharedFile.send(ID tohost, ISharedFileSendProgressListener listener)
Which would block the caller thread until the send was complete.
Any thoughts appreciated.
Scott
Boris Bokowski wrote:
I don't think this is a good idea - for the following reasons:
1) IFile is spec'd as "This interface is not intended to be
implemented by clients", i.e. new methods might be added to this
interface at any time, breaking any existing implementers of IFile.
2) You would have to implement all of the methods on IFile and
IResource, it's a very long list, and many of the operations don't
make sense in the case of file transfer.
3) It would be difficult to add behaviour that is not already part of
IFile. As an example, some FTP servers support resuming a file
transfer, so you might want to support a call like
aFile.resumeContents(position).
Boris
On 8/31/05, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
...
IFile aFile = fscont.getFileForLocation("path/to/file/plus/name");
// get contents of file
if (aFile != null) {
InputStream contents = aFile.getContents();
// read from stream and do whatever with it...e.g. save, etc
}
// the underlying provider implementation would implement this in the
protocol-specific way...e.g. read stream with ftp get, etc
What do you think of this 'style' of implementing file transfer? It
sort of makes the ECF container into a virtual file system...and it
leverages off of the existing org.eclipse.core.resources.* semantics
(and implementation I expect). One problem, though, is that the
aFile.getContents() call would necessarily be blocking, and we may want
to provide an IFile adapter that allows for asynchronous retrieval of
contents with notification.
Let me know what you think.
Scott
