Yes, you split the application. UI
elements are kept at the terminal and
the application at the CPU server. The input event generator knows
what's
the input, but it runs at the terminal.
The only problem is to come up with a
widget abstract and generic enough.
El 20/03/2009, a las 14:07, rogpe...@gmail.com escribió:
2009/3/20 Charles Forsyth <fors...@terzarima.net>:
in the slow-network situation the thing you're responding to on the
display
might not be accurate (eg, feedback delayed) which low-level input
merging
won't address.
true, but that's something that's relatively easy for the user
to adjust to - most actions have an easily perceived visual
result, and if that hasn't happened, i won't initiate my
next action.
in fact it's a problem with any slow-responding UI,
which is where nemo's point about splitting things up
at a higher level comes in. and that's what (in an extremely
clunky way) the AJAX thing is all about too.
the problem with choosing a higher level of abstraction is that
the input event generators can't in general be agnostic about
what the mouse/keyboard/whatever are operating on,
so you end up with a smart client or split application,
which lack the same easy composability that you get
from plan 9's remote devices.
[/mail/box/nemo/msgs/200903/36582]
