Re: [eclipse-incubator-e4-dev] [resources] Java7 / JSR203 and EFS

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Doug,

Schaefer, Doug wrote:
> I could agree with that. I'm a bit worried about adding async operations
> to EFS. Async APIs are complicated to use (and I have tried using the
> Debug Services Framework which uses this paradigm to an extreme). 

I agree that many async APIs are complicated to use (e.g. nio), but of 
course that doesn't mean they must be complicated to use.


> I
> wouldn't want to force that on all users of EFS.
>   

I agree that a complicated API wouldn't be good to force on all API 
users...but

1) It is possible to have a less complicated async API (see ECF 
filetransfer)
2) Asynchronous access to files/resources is desirable and in some cases 
necessary (for some use cases)
3) Using (e.g.) adapters it's not necessary to force such an API on 
anyone (rather it can be available when needed)

> And I'm not convinced that features that assume the file system is close
> and local can work the same when the file system is slow and remote. 

I agree...that's why I think it makes sense to have the availability of 
asynchronous file transfer...to support those cases where the file 
system is slow and remote...and the application would like to manage the 
remoteness explicitly/asynchronously rather than having the filesystem 
attempt to hide the differences between local and remote.

> I
> have to believe that workflows and designs would be different.
>   

Agreed.

> To that extent, let's start assuming that files are quick and local. And
> let's investigate how we could leverage ECF to support remote file
> systems. If that doesn't meet our needs, we can always add async later.
>   

Sounds reasonable.  Just as an aside: I think there's a lot of potential 
to use asynchronous file transfer + replication to do caching of remote 
resources.

Scott