couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <>
Subject Re: JSONQuery
Date Tue, 10 Mar 2009 12:23:54 GMT
On Tue, Mar 10, 2009 at 7:12 AM, Jan Lehnardt <> wrote:

> On 10 Mar 2009, at 13:07, Paul Davis wrote:
>  On Tue, Mar 10, 2009 at 7:59 AM, Dean Landolt <>
>> wrote:
>>> On Tue, Mar 10, 2009 at 6:50 AM, Noah Slater <> wrote:
>>>  On Tue, Mar 10, 2009 at 07:43:16AM -0400, Paul Davis wrote:
>>>>> Haven't we discussed this before? Or am I just getting a weird déjà
>>>> Well, we've certainly discussed JSON paths, JSON queries, and JSON
>>>> diffs.
>>>> I didn't think this specific suggestion has come up before, apologies.
>>>> I still think this is low hanging RFC fruit. Heh
>>> We had discussed JSONPath, which at first glance this is, but it looks
>>> like
>>> they cleaned it up quite a bit. It's even got pythonic list slices so
>>> this
>>> is definitely *not* javascript -- it's just that the reference
>>> implementation is in js, and that's the only implementation...for now.
>>> Looking at the new spec, I've already implemented half of this in python
>>> --
>>> I'd be happy to take it all the way if this would help formalize path
>>> semantics in couch.
>> If its done in JS its probably done in Python [1] (shameless plug).
>> The bigger issue is how to get an Erlang implementation. I mentioned
>> to Jan about trying to link spidermonkey directly into the Erlang VM.
>> He said some guys have tried and it ended in abandonment because JS
>> was too unstable. Though it does sound like a fun experiment.
> "Some Guys" being the original Erlang & OTP developers :) They do not
> recommend going down that route.

What do they know ;)

But actually Paul, I was just mentioning a pure python parser as a proof of
concept to show JSONQuery doesn't need js. In fact, if you look at the new
spec Noah linked to, it's not even *close *to js (it strikes me as more like
a jumble of python and ruby with some xpath tossed in).

As an example of what I mean, JSONSchema already has an implementation in
another language (in this case, python again[1]). And JSONQuery even less
javascript-idiomatic. If you'd like, I'd be happy to try my hand at
implementing it in erlang -- but I was thinking it would be most helpful for
view ops (thus, in js). It would be pretty convenient if there were
agreed-upon path semantics -- specifically for things like searching.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message