Re: [ecf-dev] Files

[Boris Bokowski <bokowski@xxxxxxxxx>]

Hi Scott,

I have just learned that a new API for 'abstract' files (without the
dependency on java.io.File) is being worked on. A first cut should be
available on dev.eclipse.org soon. The bug report to track is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=106176.

Boris.

On 9/2/05, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> 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
> >>
> >>
> 
> 
>