Comments on: Synchronizing Client Models

By: Josh Rehman

Josh Rehman — Sun, 11 May 2008 08:45:35 +0000

Interesting article, but it seems to me that create+update should rarely if ever occur in a real application. The whole point of the client software is to transform user gestures into data, accumulate that data until it’s ready to construct a message, send the message, and then render the response. (The sum total of these messages represent the entire independant data for the system and is quite precious because humans labored to provide it.)

In the UI a user might see a modal dialog on Person.create, meaning that a user would not have an opportunity to give the app any gesture that could be interpreted as Person.update for some time. Indeed, giving the user the opportunity to make an update gesture is a mistake, since Person.create may very well fail. If create() fails then update() is wasted effort. And nothing is more frustrating to a user than to waste their precious effort wrangling chaotic thoughts into the straightjacket of a form field, and then to have to do it again!

The only three circumstances I can see create+update happening: a synthetic test, the result of UI that may be a little bit broken, or because of an architecture that mixes independent and dependent data. A queue just masks the underlying problem, IMHO.

By: Jen

Jen — Sun, 13 Apr 2008 13:49:51 +0000

Very nice Oliver!

By: graste

graste — Sat, 05 Apr 2008 23:58:34 +0000

..I just had a quick look at the files. Never spec’d javascript before. Looks nice. I don’t have time for a deeper look atm, but will definately try using the queue ball implementation in case I need something like that the next weeks.

By: oliver

oliver — Sat, 05 Apr 2008 16:26:00 +0000

Thanks for the comment. You raise an interesting set of observations and questions, and I’ll think more about it at length.

A quick update on queue ball: you can download it from http://github.com/osteele/mop-js, and you can get a little bit of a taste for how to use it in the specs in that repo, but I haven’t had a chance yet to write up exactly how to use it for the problem described here.

By: graste

graste — Sat, 05 Apr 2008 15:29:39 +0000

…it nicely outlines a few thoughts I had about possible sync problems between server and client in an application using ruby on rails. I was surprised, that many examples of rails helpers just use these XHR capabilities of todays javascript libraries without further annotations. Even small updates/manipulations/additions are sometimes done using server-side actions, which do CRUD operations on model objects and/or deliver XML/HTML results. Not that this is wrong or problematic by default, but I was wondering about traffic, number of requests and race conditions. In very simple cases there are no problems, of course. When it gets more complex I’m unsure about the practicalness of the basic examples and what to do, to handle the potentially occurring issues. Additionally the solution always depends on the user interface, its workflows and the overall usability/accessability.

My conclusion was, that – now that it’s relatively easy to use basic XHR in applications – there is still no clear or widely used solution which handles queueing and race conditions in such apps. At least nothing with “drop-in-be-happy” functionality that I’m aware of. Perhaps it’s only a theoretically relevant problem, that nobody cares about? I can’t imagine that. At least the companies with AJAX-heavy applications should’ve noticed some edge cases and worked around them.

Enough for the babbling and as I said: Thanks for the interesting article – I read it about two or three times the last month.

One question though: Any advances with the queue ball yet?

By: Kevin Reid

Kevin Reid — Thu, 28 Feb 2008 16:05:43 +0000

This looks very much like E’s message-passing semantics. In E, a reference can be a “promise”, which means that its referent has not been determined yet (during a network request, for example). Messages sent to promises are queued, in order, until the promise is resolved (but are sent over the network promptly, to reduce roundtrip delays).

Your buffering messages in a Person until the id is known, then delivering them in order once it is, is essentially what an E promise does. (Unlike your Serialized.post, the messages are delivered without waiting for responses, because the protocol is defined so that the target receives messages in order over a single connection).

Tyler Close’s web-calculus is a related system (I’m not thoroughly familiar with it myself) designed to work over HTTP.

I look forward to seeing if your “Queue Ball” is a generic eventual reference implementation.

(If you’re interested in hearing more about E, feel free to contact me.)