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.
