y, May 11, 2006 2:29 PM
To: java-dev@lucene.apache.org
Subject: Re: Taking a step back
I don't want to get into this (so I'm replying!?), but I just want to point
out 2 things:
1) So far we've never had a situation where Java Lucene was held back
because of interoperability. Ports t
file format, it bit me in the ass in
the end... and/or severely limited the ability of myself or others to
change...
-Original Message-
From: Otis Gospodnetic [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 11, 2006 2:29 PM
To: java-dev@lucene.apache.org
Subject: Re: Taking a step back
I
the HTTP server thing that you are describing, I believe.
Otis
- Original Message
From: Robert Engels <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Thursday, May 11, 2006 1:37:17 PM
Subject: RE: Taking a step back
I disagree with that a bit. I have found that certain language
ursday, May 11, 2006 12:08 PM
To: java-dev@lucene.apache.org
Subject: Re: Taking a step back
On May 10, 2006, at 8:02 AM, Robert Engels wrote:
> The file format issue whoever is a non-issue. If you want
> interoperability
> between systems do it via remote invocation and IIOP, or some
tting [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 11, 2006 12:20 PM
To: java-dev@lucene.apache.org
Subject: Re: Taking a step back
Marvin Humphrey wrote:
> The only question is whether there are Java-specific optimizations
> which are so advantageous that they outweigh the benefits of
> inte
Marvin Humphrey wrote:
The only question is whether there are Java-specific optimizations
which are so advantageous that they outweigh the benefits of
interchange.
It's not just optimizations. If we, e.g., wrote, for each field, the
name of the codec class that it uses, then we could provi
Marvin Humphrey wrote:
If Lucene is to stay usable and maintainable, some people, some times,
have to be told "thank you, but no".
There's lots of talk. Fortunately, in this case, the talk to patch
ratio is typically high in open source projects.
Doug
-
On May 10, 2006, at 8:02 AM, Robert Engels wrote:
The file format issue whoever is a non-issue. If you want
interoperability
between systems do it via remote invocation and IIOP, or some HTTP
interface. This is far more easier to control, especially through
version
change cycles - otherwise
On May 10, 2006, at 4:05 AM, Grant Ingersoll wrote:
As I see it, we have several people proposing file format changes,
Otis and some others want scoring changes, I have discussed with a
few people the ability to make more pluggable how fields are
indexed plus the ability to add metadata at
Bill Janssen wrote:
Have you put a field in the file format yet that gives its version?
Alternatively, is there a way to find out which version of Lucene
needs to be used with a given index?
The segments file has a format number, as do many other files, but the
segments file is the only file g
On Wed, 2006-05-10 at 11:13 -0700, Doug Cutting wrote:
>
> File formats are back-compatible between major versions. Version X.N
> should be able to read indexes generated by any version after and
> including version X-1.0, but may-or-may-not be able to read indexes
> generated by version X-2.N.
>
On Wed, 2006-05-10 at 11:13 -0700, Doug Cutting wrote:
> File formats are back-compatible between major versions. Version X.N
> should be able to read indexes generated by any version after and
> including version X-1.0, but may-or-may-not be able to read indexes
> generated by version X-2.N.
>
>
> File formats are back-compatible between major versions. Version X.N
> should be able to read indexes generated by any version after and
> including version X-1.0, but may-or-may-not be able to read indexes
> generated by version X-2.N.
>
> Note that older releases are never guaranteed to be
ng [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 10, 2006 1:14 PM
To: java-dev@lucene.apache.org
Subject: Re: Taking a step back
Lucene version numbers are about compatibility.
Minor versions should always have complete API back-compatiblity.
That's to say, any code developed against X.0 sho
Lucene version numbers are about compatibility.
Minor versions should always have complete API back-compatiblity.
That's to say, any code developed against X.0 should continue to run
without alteration against all X.N releases. A major release may
introduce incompatible API changes. The tran
On Wed, 2006-05-10 at 13:29 -0400, Grant Ingersoll wrote:
> Or even Lucene3Whiteboard (did I really write Lucene 3?!?)
You know, I was just thinking that it would be nice if Lucene was
developed like the Linux kernels. When 2.6 is stable, people are beta
testing 2.7 and some hack 2.8.
Sure, or even a place called Lucene Planning or Lucene Strategy. Just
not sure if it should be only on the Java side or not. Or even
Lucene3Whiteboard (did I really write Lucene 3?!?)
Otis Gospodnetic wrote:
You mean you want us to be more organized!?!? :)
I think a Wiki page like
http://wi
speaking of the wiki, we need to move it to /lucene instead of the
old /jakarta-lucene. I've copied infrastructure on this message to
find out what we need to do to shift it.
Erik
On May 10, 2006, at 11:30 AM, Otis Gospodnetic wrote:
You mean you want us to be more organized!?!
You mean you want us to be more organized!?!? :)
I think a Wiki page like
http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard might help. Something
like http://wiki.apache.org/jakarta-lucene/Lucene2.1Whiteboard
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To:
I agree with almost all of what you said.
The file format issue whoever is a non-issue. If you want interoperability
between systems do it via remote invocation and IIOP, or some HTTP
interface. This is far more easier to control, especially through version
change cycles - otherwise all platforms
20 matches
Mail list logo
