couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: partial/diff updates?
Date Fri, 28 Nov 2008 05:31:15 GMT

On 27 Nov 2008, at 20:55, Antony Blakey 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?
>
> 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 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). 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. 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 :)

I feel that there are far more important things that we should get out  
for 0.9 and 1.0 before looking at partial updates. :)

Cheers
Jan
--

Mime
View raw message