[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lucene-dev
Subject:    Re: "xml" query parser, except with JSON
From:       mark harwood <markharw00d () yahoo ! co ! uk>
Date:       2007-01-30 9:53:46
Message-ID: 16207.61380.qm () web26007 ! mail ! ukl ! yahoo ! com
[Download RAW message or body]

Hi Erik,
I've not done much with JSON but it looks like it might be an interesting approach.

> > Is it possible to introduce a new  serialization format without rewriting the \
> > whole parser?

Unfortunately, the XML DOM permeates it's way throughout the existing parser design.

Some initial observations:

1) I suspect JSON offers simpler programmatic construction of queries for clients \
rather than having to construct XML using the DOM api 2) XML does have the nice \
option of being able to use XSLT to populate query templates with user input. Having \
the query templates as an externalized .xsl file held on the server is quite nice. \
QueryTemplateManager offers support for this mode of working. 3) Adding JSON will \
presumably introduce a dependency on some third party library with the usual license \
hassles. 4) XML or JSON, it makes sense to avoid making the serialization format \
mirror exactly the existing Lucene query/filter objects because this could either \
make the serialization format ugly or require changes to the existing Lucene objects \
to make them "serialization friendly". The XML parser addresses this with a suite of \
"Builder" classes which parse different parts of the idealised XML syntax and \
constructs the appropriate Lucene queries/filters. I imagine a JSON variant would \
address this by supplying a set of "criteria" classes used to construct a complex set \
of query criteria which can then be serialized on the client as JSON and then \
deserialized by the Lucene server. Maybe these "criteria-only" classes could be \
serialized to XML too as a more convenient way of constructing XML? 5) I think we \
need to think about what we are trying to achieve before picking a technology. \
Lightweight clients? Readable query representations? Size? Speed of parsing? Ease of \
query construction in clients? Checking of valid queries? Broadest support for \
different clients? Option of  templates?

Cheers
Mark

----- Original Message ----
From: Erik Hatcher <erik@ehatchersolutions.com>
To: solr-dev@lucene.apache.org
Cc: java-dev@lucene.apache.org
Sent: Tuesday, 30 January, 2007 3:21:52 AM
Subject: "xml" query parser, except with JSON

I'm curious, Mark, what you think about the XMLQueryParser being  
morphed into a JSON query parser.  Is it possible to introduce a new  
serialization format without rewriting the whole parser?  Or is it  
intimately tied to XML throughout?

Solr could really benefit from allowing queries to be pushed down to  
the client.  XML works, for sure, but I have a feeling Yonik's JSON  
parser would be faster than an XML parser.  Thoughts?

Thanks,
    Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org






		
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your \
Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]