lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Language neutral index format representation
Date Tue, 02 Dec 2003 19:36:53 GMT
On Tuesday, December 2, 2003, at 01:56  PM, Simon Cozens wrote:
> Yep, thanks to Kasei, who are also cleaning up and documenting the 
> code I
> write. For the interested, what I'm doing is at
> http://cvs.simon-cozens.org/viewcvs.cgi/plucene/ and I hope to sync 
> back over
> the docs/tests once they're completed.

Speaking of tests - are you testing Java/Perl interoperability?  For 
example - are you testing an index created in Java is read fine by your 
Perl API?  And vice versa?  I'm interested in developing some sort of 
test suite to do this with the Ruby port eventually.

> My version's almost there, thanks to a month basically full-time work 
> on it.

I'm jealous!  Or I guess you might say I should forget Ruby and switch 
to Perl :)

> I believe so. You'd generate, conceptually, an ObjectSerializer class 
> of
> some sort which has read and write methods, which is overloaded to do
> the right thing with the right object type.

I'm thinking more in terms of generating classes like FieldInfos and 
SegmentInfos from an XML descriptor that represented the info here:

	http://jakarta.apache.org/lucene/docs/fileformats.html

> However, I can imagine some snags, such as the one which prompted this
> thread: how would you represent sequences of objects with their 
> properties
> delta-encoded, for instance, or the cunning buffer-substring trick 
> used to
> store the terms in the .tis file?

I view this as what the language-specific code generator would build 
from a general file format descriptor.  For example, in Java I'd 
probably write some Velocity templates that keyed of the XML 
descriptor.  In Ruby, I'd use REXML and ERb templates.

I haven't thought through any detailed issues that could come up or if 
it would impact the design of the Java "reference implementation" to 
accommodate generated code or not.

	Erik


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


Mime
View raw message