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 _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
