Re: [eclipse-incubator-e4-dev] [resources] Java7 / JSR203 and EFS
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.
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
1) It is possible to have a less complicated async API (see ECF
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.
have to believe that workflows and designs would be different.
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