- From: Robert Sayre <rsayre@mozilla.com>
- Date: Sat, 16 Feb 2008 18:39:05 -0500
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Feb 16, 2008, at 4:43 PM, Roy T. Fielding wrote: > > I think your json.sync > format is close, but way too verbose (we are supposed to be saving > bandwidth here, not being human-readable). Well, it's tricky, because a conflict will not save bandwidth, so it's best to include enough information to avoid as many as possible. Users don't like them anyway. I agree it's a bit of a failure for changes in long strings of text. Worse is better, or something. A nice extension might be a "value" key with an object field containing text offsets. Regarding the key names and things, I'm clearly not trying hard. But I think JSON-as-patch-format has advantages that make it desirable. Easy to sniff character set, ascii escapes for control characters (mandatory in Mozilla's JSON encoder, and Crockford's), optional ascii escapes for unicode, and Web ubiquity. It's possible to implement in JS, for older browsers and browsers that lag intentionally. Bandwidth can be further crunched by gzip or macros in the transfer protocol (nudge, nudge). > Maybe I should start a > wiki for diff formats and just start registering them. Sounds good. FWIW, there are still a few edge cases left to deal with in the JSON sync thing, and I don't have time to work on them. I would also like to sit down and prove it, like Ramsey did, but that's going to be tedious and time-consuming. I won't get to it until summer. I can document this in an I-D if other people are willing to help me take it to the finish line. - Rob
Received on Saturday, 16 February 2008 23:39:21 UTC