[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous
|
Hi David and all,
BTW, I agree with and appreciate Kevin's summary of this thread...as I
think it does boil down to wanting to present simple/sync API for common
case, vs needing to allow 'worst case' (network) operation of EFS.
David Orme wrote:
> 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...
I happen to like very much the use of Futures...as a way to leave up to
the client how to do RPC in slow/potentially blocking/async environment.
Another oft-used pattern is the asynchronous listener e.g.
sendRequestToDoSomething(target,listener) where listener is a callback
that is called by a separate thread/job when various events occur. IMHO
this is particularly useful with request/response protocols (like http).
Futures have some nice advantages over alisteners:
a) No need for lots of other listener/event classes
b) Easy to specify timeouts/waiting for completion (as Dave says above)
c) naturally fits for call/return semantics
d) very 'clean'
OTOH alisteners have some advantages
e) more understood/used (that's my opinion...that might be just me)
f) allows more flexibility for progress reporting/i.e. multiple events
to listeners
g) easier to extend (i.e. new events)
Perhaps EFS could be examined for what operations are good candidates
for asynchronous (e.g. deep refresh) , and then asynchronous methods
could be created/added (keeping the blocking/sync methods) that use
either futures or alisteners (perhaps as adapters...whatever makes sense
for overall EFS clarity/simplicity). Then EFS can/could remain the same
for local/fs access (with changes/fixes as Martin identifies) but also
support asynchronous access...using futures, alisteners, other patterns
perhaps.
Scott
-Dave Orme
On Oct 28, 2008 5:04 PM, "Kevin McGuire" <Kevin_McGuire@xxxxxxxxxx
<mailto: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 <mailto:slewis@xxxxxxxxxxxxx>>*
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
<mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx>
10/22/2008 07:16 PM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx
<mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>>
To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx
<mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>>
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
eclipse-incubator-e4-dev@xxxxxxxxxxx
<mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
------------------------------------------------------------------------
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
