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]
