couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: partial/diff updates?
Date Fri, 28 Nov 2008 04:55:30 GMT

On 28/11/2008, at 2:02 PM, Paul Davis wrote:

> I think what Noah might be saying is, "As soon as there's a JSON diff
> RFC, we'll implement it". Which I agree with completely. Until then,
> if we implement something it'd most likely be not the RFC which we've
> all had to deal with when coding to web 'standards'. It's not fun.
> That said, pushing the JSON community towards acceptance of a diff
> format is something we could do. Not sure how we should organize other
> than all joining the JSON lists and pushing. And then nominating Noah
> to write the RFC that we'll implement. Matter of fact I kinda like
> that idea. Anyone with me?

All IMO (of course) ...

There's no guarantee that a JSON diff RFC will happen in any  
reasonable time frame if it doesn't arise from this group, which has a  
specific need in mind. And I've had plenty of problems coding to web  
standards that are RFC's. Even when there is an RFC there is no  
guarantee that it is unambiguous or correctly implemented - witness  
the recent discussion about duplicate names in JSON hashes.

Furthermore, there's no guarantee that a proposal from the JSON  
community will be appropriate. Consider the current JSONPath proposal  
linked from (acknowledging that JSONPath might not be a  
component of a diff spec). It presumes a script engine, and IMO only  
an explicitly declarative model without the need for expression  
evaluation would be suitable for Couch (which doesn't mandate a JS  
engine). As an example, consider a reference to the last element of an  
array, which in the current proposal is like this:  
"$[(@.length-1)]". You could use an explicit index, but  
that presumes you have the entire structure of interest. I can imagine  
wanting to generate a stream of partial updates that append to a list,  
where you don't want the client to have to track the entire list  
structure. One response might be 'write them as separate documents',  
but then you are forced to fake-join/merge in your view, which can get  
very complicated, and run into intermediate documents that expand  
during (re)reduction.

Finally, why does this have to be driven through the 'JSON community'.  
Given that Couch is an *alpha* product, this is a good time to  
implement something, which IMO is the best way to prove a particular  
model. Why not just implement something to get a feel for suitability?  
We don't have to push anyone, we just have to do it, surely? And yes,  
I understand the inherent irony of that statement :)

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Every task involves constraint,
Solve the thing without complaint;
There are magic links and chains
Forged to loose our rigid brains.
Structures, structures, though they bind,
Strangely liberate the mind.
   -- James Fallen

View raw message