| Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous |
> timeouts
This is almost certainly naive, but maybe not...
What if all file system operations run in Runnables, in a Future. By default we could future.waitFor(timeout).
The operation would have a tri-state "return value": success/fail/notDoneYet.
So some complexity would unavoidably leak into the API. But maybe we could document some cases that will always be synchronous...
One thought...
-Dave Orme
On Oct 28, 2008 5:04 PM, "Kevin McGuire" <Kevin_McGuire@xxxxxxxxxx> wrote:
Just getting caught up on this thread, great discussion.
Some time ago I made the statement that maybe we should assume that all data is remote/slow, and too large to bring local, then determine the right resource model to support it. The notion would be that if in fact I was local and fast, then its a bonus, since naively things that are written kindly towards being slow just work better if its in fact fast.
But I realize now from this discussion that misses important realities:
1) The programming model for working async is much harder.
Meanwhile, one of our stated goals for e4 is to make programming in Eclipse easier. I'd love for us to handle better remote and big resource sets, but I'm not sure I want to sacrifice anything in the typical local programming to do so. Thus I want to program sync for fast things and async for slow things. Unfortunately that's two APIs, two slightly different programming models, and ignores the fact that I (the programmer) might not be able to guess if its the slow or fast performing case (the example mentioned of a network share is a good one).
2) The UI is different.
Right now we try to do tricks for jobs/progress to try to optimize for short jobs (e.g. delay showing the monitor), since there's nothing more distracting that progress dialogs that appear and disappear. We're really trying to cheat and provide two UI experiences, one for fast cases which happen to be wrapped in jobs, and one for the real slow/async ones. But we fail in a different way, since a delay before the appearance of a progress monitor can be disconcerting and provide the false impression that the system is sluggish. Thus ideally you'd get the right UI from the start, not based on the type of task, but rather on its real performance characteristics (Step 1: build time machine, Step 2: time the operation, Step 3: go back in time and choose which UI to expose).
Inherently there's the question of whether to allow people to do other tasks while the initial task is completing. Often this is in the nature of the task. Lets say I'm drag/dropping a file. From a user task point of view, this is a synchronous and continuous task. If quering the drop targets was, for sake of argument async, that doesn't help me, since the operation must continue to have the illusion of being synchronous otherwise bad things will happen (imagine a progress dialog showing up, how odd). Ideally though we'd like to have a reasonable timeout, so that if for some reason the file system wasn't responsive, then the UI didn't remain hung forever.
Regards,
Kevin
Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx10/22/2008 07:16 PM
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx> Subject Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous
Hi Martin, I agree with your examples below. RE: proper programming patterns...I think this is...
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev