Re: [ecf-dev] Files

[Boris Bokowski <bokowski@xxxxxxxxx>]

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