Re: [9fans] Raw Input Driver

["Fco. J. Ballesteros" <nemo@lsub.org>]

If connection is slow (as the one I'm using now) increasing the
abstraction level is a good thing to do. Merging low level input
streams may patch up things for a while, but won't be enough
if the connection is slower.

Separating the viewer form the application reduces coupling a
lot and makes kbd/mouse events a non issue. For example, in
the o/live I'm using to type this all of mouse/kbd/draw interaction
happens at the terminal. The editor, running at the cpu server,
gets only high-level events like "this was inserted" or "the user
is looking for this" or "the user wants to run that".



>  From: rogpeppe@gmail.com
>  To: 9fans@9fans.net
>  Reply-To: 9fans@9fans.net
>  Date: Fri Mar 20 12:31:54 CET 2009
>  Subject: Re: [9fans] Raw Input Driver
>
>  2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
>  > the ordering problem is misleading: you need timely response for
>  > interactive applications; it's a reasonably straightforward application
>  > of real-time programming.  (by the way, if you're passing low-level
>  > things like that across lossy wireless networks, you're possibly
>  > not addressing the most relevant problem first.)  the effects you're trying to synchronise
>  > are typically changes to data structures inside a program (including effects on the display),
>  > so that's where the synchronisation and interlocking should be.
>
>  does that mean we shouldn't do graphics over cpu over a slowish
>  connection? because as things stand, ordering can easily get
>  mucked up in that case, and in acme that leads to situations where typed text
>  you expect to go in one window actually goes into another.
>
>  i don't think there's a solution to this at the client side (key presses
>  don't arrive with timestamps, and even if they did, how long would we
>  wait?), so i can understand people thinking about a server-side
>  solution.
>
>  one possibility would be to have a server that did a general
>  "merge event files" operation, and have the importing client do the
>  de-multiplexing
>  operation - that way at least you'd get the same file interface.
>  but there's still no guarantee.
>
>  yes, the streams are separate at the originating source,
>  but they actually originate from the same
>  person, who has a pretty good idea of which event they generated
>  first. when that information can get lost in transit,
>  giving unexpected results, there's something wrong.