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 19:28:31 GMT
Per JSON specification, emphasis mine:

“An object is an unordered collection of zero or more name/value pairs…”

Any ordering difference the xdelta approach would catch would therefore
be spurious.

Paul

On Fri, 2011-06-10 at 14:06 -0400, Dave Bender wrote:

> 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