Re: [9fans] Raw Input Driver

[roger peppe <rogpeppe@gmail.com>]

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.