RE: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi Scott,

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
back-ends.

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

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

Can anybody argue against using the asynchronous ECF 
filetransfer APIs as the core E4 resources file system
layer?

Cheers,
Martin