From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9f6b6afb208715c0f2db6433d94f8b21@terzarima.net> References: <2470057889c7c25d3cf6c0284b3bcc73@quanstro.net> <9f6b6afb208715c0f2db6433d94f8b21@terzarima.net> Date: Fri, 20 Mar 2009 13:03:12 +0000 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Raw Input Driver Topicbox-Message-UUID: c094517c-ead4-11e9-9d60-3106f5b1d025 2009/3/20 Charles Forsyth : > 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.