Re: [ecf-dev] Files

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Thanks Boris.

This looks pretty interesting.  ECF could provide group implementations 
(peer to peer or client/server) of this abstract file system.

Scott


Boris Bokowski wrote:

> 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
> > > >
> > > >
> > > >        
> >
> >