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: rogpe...@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 <fors...@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.
