incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <paul.joseph.da...@gmail.com>
Subject Re: partial/diff updates?
Date Fri, 28 Nov 2008 05:38:33 GMT
On Thu, Nov 27, 2008 at 10:55 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>
> 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?
>

It's a holiday and I've had beers so I'm taking the lazy method of not
Googling and refuting sentence by sentence

> 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.
>

Any JSON diff format is going to require the JSON RFC's 'SHOULD' to
either be changed to a 'MAY' or 'MUST'. The ambiguity in 'SHOULD' is
going to cause problems.

> Furthermore, there's no guarantee that a proposal from the JSON community
> will be appropriate. Consider the current JSONPath proposal linked from
> www.json.com (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).

I agree entirely. The 'SHOULD' would've been much better as a 'MUST'.

 As an example, consider a reference to
> the last element of an array, which in the current proposal is like this:
> "$.store.book[(@.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.

Or we could use a array[-1] syntax like some languages. Tracking the
entire list is pretty much out of the question. Take it for granted
that CouchDB is going to store entire documents. Any diff format that
is used will only be an optimization for editing documents.

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.
>

I'm not sure what you mean by this.

> 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 :)
>

In my mind there are two methods in this scenario. The IE way, and the
not IE way. IE coded to their whims and desires. I would be very
unsettled if CouchDB took it upon itself to implement a custom spec of
JSON diff without input from the community. You get into the whole
support/breaking changes issues that suck.

As Jan mentioned, there's no actual proof this is even needed yet
beyond most of us *thinking* it would probably be a good thing.

> 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
>
>
>

Mime
View raw message