On Jan 8, 2009, at 6:28 AM, Antony Blakey wrote:
On 08/01/2009, at 9:11 PM, Geir Magnusson Jr. wrote:
Eh?
1) This is the *ideal* place to explore diff support. JSON came
about because someone just did it and built things with it.
Totally agree.
2) Couch could easily support an update mechanism that would then
be deprecated once Real(TM) "JSON diff" support showed up.
I certainly don't want to write an RFC, but the condition was that
partial updates wouldn't be considered unless it was an
implementation of an RFC, and if an RFC existed, it would very
likely be incorporated.
I'd expect that from Oracle, not a newly-minted Apache project with an
evolving codebase in a hot, emerging sector of the cloud technology
space :)
Re-reading, I take that back. I know of cases where IBM and BEA both
put "evolving" APIs into their GA-released code for customers to use,
while at the same time bringing them to the JCP. SDO and Work
Manager, IIRC. In theory very healthy - the customer experiences of
IBM and BEA could be fed back into a broader expert group to produce a
spec that was based on the real world.
Fantastic. So why don't you both implement your ideas in Couch and
then let a broad spectrum of users w/ diverse applications test
them and give feedback? That seems like the only way something
sane can come out.
Our disagreement was about the nature of the RFC - http://groups.google.com/group/json-diff/browse_thread/thread/595370127b665611
.
AFAIK Noah wasn't planning to do an implementation, and without in-
principle PMC agreement, it's not going to happen.
I guess you can do RFCs w/o implementations, but I thought that apart
from April 1 RFCs and memos, RFCs were driven by real-world
experiences...
IMO there are more important, fundamental issues to deal with before
CouchDB commits to a released API.
Like getting _rev and _id out of the user data :D
/me ducks
geir
