incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul C. Bryan" <paul.br...@forgerock.com>
Subject Re: JSON Patch Internet Draft 01
Date Fri, 10 Jun 2011 17:45:39 GMT
On Thu, 2011-06-09 at 18:03 -0700, Jens Alfke wrote:

> To play devil’s advocate: Is this format really necessary? From the draft:
> 
> >    The HTTP PATCH [RFC5789] specification extends HTTP with a new method
> >    to perform partial modifications to resources.  A JSON-based patch
> >    document type is required to modify JSON documents using this method.
> 
> That’s not strictly true. A generic delta format such as xdelta3 or zdelta can be used
to patch any type of resource at all (and frequently is, in apps like software updaters.)
> 
> I can see that an advantage of JSON Patch is that, since it describes structural changes
rather than byte-level changes, it works even if the physical representation of the JSON changes
(i.e. modifications to whitespace or Unicode character encoding.)

As you point-out the challenge in using these generic formats is the
requirement of a byte-identical document representation. This implies
that the document either be stored in this serialized format, or there
is some normalization scheme that ensures that the document is always
formatted consistently before taking a patch.


> I’m just unsure whether that’s a significant enough advantage to outweigh the drawbacks,
including:

I expect in some cases, it would not. In our application, we can't make
assumptions of the serialized expression of a JSON document, and hence
such a format is justifiable.


> - Much more verbose than xdelta3 or zdelta
> - More CPU-expensive to patch
> - Requires new software to generate and apply patches, rather than using existing delta
libraries
> - Has no error checking, so version mismatches could result in uncaught document corruption

Are HTTP conditions not sufficient to resolve this?


> —Jens



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message