Building your own parser with Antlr is really easy. Using Ragel is harder, but yields insane parsing performance. Is there any reason to worry about library-bundled parsers if you're making something more complex then a college project?
On Tue, Dec 9, 2008 at 01:49, robert engels <[EMAIL PROTECTED]> wrote: > The problem with that is that in most cases you still need a "string" based > syntax that "people" can enter... > > I guess you can always have an "advanced search" page that builds and > submits the XML query behind the scenes. > > > > On Dec 8, 2008, at 4:40 PM, Erik Hatcher wrote: > >> Well, there's the pretty sophisticated and extensible XML query parser in >> contrib. I've still only scratched the surface of it, but it meets the >> specs you mentioned. >> >> Erik >> >> >> On Dec 8, 2008, at 4:51 PM, robert engels wrote: >> >>> I think an important piece to make this work is the query parser/syntax. >>> >>> We already have a system similar to what is outlined below. We made >>> changes to the query syntax to support our various query extensions. >>> >>> The nice thing, is that persisting queries is a simple string. It also >>> makes it very easy for external system to submit queries. >>> >>> We also have XML definitions for a "result set". >>> >>> I think the only way to make this work though, is probably a more >>> detailed query syntax (similar to SQL), so that it can be easily extended >>> with new clauses/functions without breaking existing code. >>> >>> I would also suggest that any core queries classes have a representation >>> here. >>> >>> I would also like to see a way for "proprietary" clauses to be supported >>> (like calls in SQL). >>> >>> On Dec 8, 2008, at 3:37 PM, eks dev wrote: >>> >>>> That sounds much better. Trying to distribute lucene (my reason why all >>>> this would be interesting) itself is just not going to work for far too >>>> many >>>> applications and will put burden on API extensions. >>>> >>>> My point is, I do not want to distribute Lucene Index, I need to >>>> distribute my application that is using Lucene. Think of it like having >>>> distributed Luke, usefull by itself, but not really usefull for slightly >>>> more complex use cases. >>>> My Hit class is specialized Lucene Hit object, my Query has totally >>>> diferent features and agregates Lucene Query... this is what I can control, >>>> what I need to send over the wire and that is the place where I define what >>>> is my Version/API, if lucene API Classes change and all existing featurs >>>> remain, I have no problems in keeping my serialized objects compatible. So >>>> the versioning becomes under my control, Lucene provides only features, >>>> library. >>>> >>>> Having light layer, easily extensible, on top of the core API would be >>>> just great, as fas as I am concerned java Serialization is not my world, >>>> having something light and extensible in etch/thrift/hadop >>>> IPC/ProtocolBuffers direction is much more thrilling. That is exactly the >>>> road hadoop, nutch, katta and probably many others are taking, having comon >>>> base that supports such cases is maybe good idea, why not making >>>> RemoteSearchable using hadoop IPC, or etch/thrift ... >>>> >>>> Maybe there are other reasons to suport java serialization, I do not >>>> know. Just painting one view on this idea >>>> >>>> >>>> >>>> >>>> ----- Original Message ---- >>>>> >>>>> From: Doug Cutting (JIRA) <[EMAIL PROTECTED]> >>>>> To: java-dev@lucene.apache.org >>>>> Sent: Monday, 8 December, 2008 19:52:46 >>>>> Subject: [jira] Commented: (LUCENE-1473) Implement standard >>>>> Serialization across Lucene versions >>>>> >>>>> >>>>> [ >>>>> >>>>> https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654513#action_12654513 >>>>> ] >>>>> >>>>> Doug Cutting commented on LUCENE-1473: >>>>> -------------------------------------- >>>>> >>>>> Would it take any more lines of code to remove Serializeable from the >>>>> core >>>>> classes and re-implement RemoteSearchable in a separate layer on top of >>>>> the core >>>>> APIs? That layer could be a contrib module and could get all the >>>>> externalizeable love it needs. It could support a specific popular >>>>> subset of >>>>> query and filter classes, rather than arbitrary Query implementations. >>>>> It would >>>>> be extensible, so that if folks wanted to support new kinds of queries, >>>>> they >>>>> easily could. This other approach seems like a slippery slope, >>>>> complicating >>>>> already complex code with new concerns. It would be better to >>>>> encapsulate these >>>>> concerns in a layer atop APIs whose back-compatibility we already make >>>>> promises >>>>> about, no? >>>>> >>>>>> Implement standard Serialization across Lucene versions >>>>>> ------------------------------------------------------- >>>>>> >>>>>> Key: LUCENE-1473 >>>>>> URL: https://issues.apache.org/jira/browse/LUCENE-1473 >>>>>> Project: Lucene - Java >>>>>> Issue Type: Bug >>>>>> Components: Search >>>>>> Affects Versions: 2.4 >>>>>> Reporter: Jason Rutherglen >>>>>> Priority: Minor >>>>>> Attachments: custom-externalizable-reader.patch, >>>>>> LUCENE-1473.patch, >>>>> >>>>> LUCENE-1473.patch, LUCENE-1473.patch, LUCENE-1473.patch >>>>>> >>>>>> Original Estimate: 8h >>>>>> Remaining Estimate: 8h >>>>>> >>>>>> To maintain serialization compatibility between Lucene versions, >>>>> >>>>> serialVersionUID needs to be added to classes that implement >>>>> java.io.Serializable. java.io.Externalizable may be implemented in >>>>> classes for >>>>> faster performance. >>>>> >>>>> -- >>>>> This message is automatically generated by JIRA. >>>>> - >>>>> You can reply to this email to add a comment to the issue online. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED]) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785
