[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Files

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