incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Bender <codeh...@gmail.com>
Subject Re: JSON Patch Internet Draft 01
Date Fri, 10 Jun 2011 18:06:04 GMT
This may be a stupid question, but how does the RFC account for the order in
which JSON map elements appear? Are these two JSON docs considered
equivalent:

A: {"a":1,"b":2}

B: {"b":2,"a":1}

The xdelta approach would catch a difference in ordering whereas the RFC
version would not.


On Fri, Jun 10, 2011 at 1:45 PM, Paul C. Bryan <paul.bryan@forgerock.com>wrote:

> 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