On 27 Nov 2008, at 09:53, Burobjorn wrote:
I like this approach.
This also creates the possibility to benchmark and compare the diff
methodology versus a full update.
The problem is that this would be a synthetic benchmark. I'd still
very much like to
see a real world application that shows in numbers that it needs
partial updates.
Until then it is just premature optimization. A neat feature for sure,
but needed,
nobody knows.
Jan
--
Would it be possible then to use
'standard' text diffs as well, without taking into account that we're
dealing with json?
All the best,
grtz
BjornW
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Concordiastraat 68-126
3551 EM Utrecht
The Netherlands
phone: +31 6 49 74 78 70
http://www.burobjorn.nl
Timo Isokoski wrote:
Is this talk about the "diff" feature related to
a) How CouchDB physically stores the data on disk
b) How data is transmitted between the client and CouchDB
In case a) I think diffs are the devil and it goes aganist the
simplicity of
CouchDB:s inner workings. In case b), wouldn't it be easy to
implement some
kind of a prototype of this feature as a "proxy server" on top of
CouchDB.
The proxy could route the normal requests directly to CouchDB and
the actual
diff requests could be handled like this:
1. GET the original document from Couch
2. Apply diff
3. PUT the modified document back to the Couch
The functionality can then be integrated into CouchDB inself if the
prototype works well and and people start using it.
-Timo
2008/11/27 Antony Blakey <[EMAIL PROTECTED]>
On 27/11/2008, at 10:10 PM, Noah Slater wrote:
On Thu, Nov 27, 2008 at 08:45:18PM +1030, Antony Blakey wrote:
* JPath its self is a nebulous concept.
In what sense do you think the concept is nebulous?
It lacks an RFC. :)
I didn't realize that JSON had an RFC! Now that I've read it, I
think that
this statement:
"A JSON text is a serialized object or array."
which dominates this subsequent statement:
"The names within an object SHOULD be unique."
clearly resolves the ambiguity discussed in a previous thread
regarding
duplicate hash keys, in the manner that I suggested. Namely,
duplicate keys
are not allowed because they cannot be the result of serializing a
javascript object. It specifically defines a JSON *text*, so model
equivalence isn't sufficient.
Given that JPath is a subset of javascript access path syntax and
semantics, would a definition that references the appropriate ECMA
clauses
meet with your approval? Or is this issue blocked IYO until a full
JSON
transformation/mutation/update RFC is approved (whatever approval
means).
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There are two ways of constructing a software design: One way is
to make it
so simple that there are obviously no deficiencies, and the other
way is to
make it so complicated that there are no obvious deficiencies.
-- C. A. R. Hoare
