From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6c41ef4c92791aa306e71d4be15901b1@lsub.org> To: 9fans@9fans.net From: "Fco. J. Ballesteros" Date: Fri, 20 Mar 2009 12:39:03 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] Raw Input Driver Topicbox-Message-UUID: c03c0224-ead4-11e9-9d60-3106f5b1d025 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 : > > 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.