lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eks dev <>
Subject Re: [jira] Commented: (LUCENE-1473) Implement standard Serialization across Lucene versions
Date Mon, 08 Dec 2008 21:37:31 GMT
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

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) <>
> To:
> Sent: Monday, 8 December, 2008 19:52:46
> Subject: [jira] Commented: (LUCENE-1473) Implement standard Serialization across Lucene
>     [ 

> ] 
> 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:
> >             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 
> 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:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message