RE: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous
good points, indeed! thanks for taking the time to write
such an elaborate reply.
> When blocking the calling thread (e.g. any synchronous reads/writes)
> results in system-wide 'problems' (e.g. UI is stopped, other server
Hm... IMHO this is not a use-case which requires async
because it couldn't get implemented with synchronous
calls. This just shows that somebody's using a synchronous
API in a way that's inappropriate for slow/unreliable
This does point out an important truth, though:
synchronous APIs may *encourage* usage of background Jobs
for slow operations, but cannot enforce this. Asynchronous
APIs, on the other hand, *force* the client to take actions
which are appropriate for use with slow/unreliable back-ends.
>From that point of view, it might actually make sense to
have the "true E4 resources kernel" only support async
file system access, and the backward compatibility wrappers
provide a bridge to synchronous access... that way we could
force "true E4" clients to take appropriate measures. Given
that ECF filetransfer is in Equinox already, I could imagine
getting rid of EFS and replacing it by ECF filetransfer
(probably extended) in the "core E4 Resources".
Futures as return value might be a concept that allows
using asynchronous APIs with minimal extra effort when
results are available "very fast and reliably".
Writing an EFS wrapper to ECF filetransfer for backward
compatibility should be an easy thing to do (and probably
you have done it already). In terms of the resource layer,
EFS is pretty separated from it already (only connected
by URI on the API). Having the Resources layer directly
make asynchronous calls (instead of using the EFS wrapper)
should be a very interesting experiment.
> Well, if such an adapter is not available then they could do it
> synchronously rather than asynchronously.
But that's exactly my point: we don't want clients having
to write code for both synchronous and asynchronous variants.
That's code duplication, resulting in bloat. I'd like to
shoot for ONE core e4 api for each concept (with additional
compatibility layers for backward compatibility where needed).
By "adding async to the EFS API" I didn't think about any
technical measure such as blowing up the IFileStore interface.
What I meant was, that clients should be able to expect any
contributed file system to be accessible with all the API
that E4 resources FS exposes -- be it synchronous or
asynchronous, via 1 or multiple interfaces, obtained via
adapter pattern or otherwise. If any bridging code is required,
it should be provided ONCE by the framework, and not by the
> I disagree. I think the problem is with trying to make local
> and remote access look exactly the same (network transparency)
Hm... on the other hand, a client that is prepared to deal
with remote files should easily be able to handle the local
case as well, no? I'd like to investigate technical measures
of how we can make it simple to program the remote case.
If the core framework is remote-aware we can add layers for
simplified access if we want. We cannot do it the other way
Can anybody argue against using the asynchronous ECF
filetransfer APIs as the core E4 resources file system