> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 10/22/2008 07:16 PM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
