W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: PATCH vs multipart/byteranges vs Content-Range

From: Robert Sayre <rsayre@mozilla.com>
Date: Sat, 16 Feb 2008 18:39:05 -0500
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <AFCA8CC5-BAD3-44E5-B529-3F18B8AA14CA@mozilla.com>
To: "Roy T. Fielding" <fielding@gbiv.com>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT