lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <thowar...@gmail.com>
Subject Re: Lucene project announcement
Date Fri, 12 Nov 2010 12:07:52 GMT
I agree with this idea completely. Standardizing the file format and
the query parser's syntax (ABNF? probably something similar exists
already since the parser is generated) would be a great start. Plus
some standards about "what criteria must a implementation of Lucene
meet to be valid?".. Obviously the unit tests are great for that, but
they are platform specific, and porting unit tests can leak bugs into
the tests... so they are not always the most reliable way to validate
a port.

One easy set of metrics is "for the following set of data <describe
some basic documents> indexed the following way <describe field
indexing settings> a valid Lucene implementation should generate
*exactly* this index <provide MD5 hashcode>... " then assuming that
passed "for the following query <describe query> searched against the
reference index just built, you should get *exactly* the following
results <list expected results>, and it should execute in less than
<indicate a timespan>."

We can build that into unit tests, but having it described outside of
code, with MD5 hashes and in a formalize manner might be more handy.

Thanks,
Troy

On Fri, Nov 12, 2010 at 12:29 AM, Prescott Nasser <geobmx540@hotmail.com> wrote:
>
> If I read you right, you're looking for a standards board of some kind to develop the
standards (file formats, QueryParser syntax, etc). I think that makes total sense, but the
way I see it, the Java group is the standards board at the moment. We are playing catch up
to get in the game, but once we are up to parity, I don't see why we wouldn't have the ability
to make suggestions and help steer the "standards"
>
>
>
>> From: Paul.Hadfield@palmerharvey.co.uk
>> To: lucene-net-dev@lucene.apache.org
>> Date: Fri, 12 Nov 2010 08:13:48 +0000
>> Subject: RE: Lucene project announcement
>>
>> It feels to be that the problem is being approached a* about face (i.e. the wrong
way wrong). Maybe it is the way that ASF works but do the constraints of Java define "Lucene,
or should it bigger than that? Should Lucene be a full text engine concept that can safely
be developed in multiple languages? I'm sure everyone would agree that it would be silly to
have different underlying file/data formats and it would definitely make sense that the rules
for processing should be the same. But could the developers behind Lucene.JAVA and Lucene.NET
work together to define an independent Lucene project and road-map, etc. This could then be
developed in each language independently of each other and heaven forbid, Oracle managed to
destroy all that is good about Java then Lucene would continue regardless, etc.
>>
>> However, if the above (dream?) could not be met, I can't see any way other than keeping
with a direct port in the short term. Once it is proven that Lucene.NET can keep up with the
Java development, then it might be possible to think about something other than a direct port.
This would simply be because every Lucene.NET release is currently trying to catch up with
'x' Lucene releases and it feels like anything other than a direct port would make that nigh
on impossible to determine what needs to be implemented in the .NET version.
>>
>> - Paul.
>>
>> -----Original Message-----
>> From: Hans Merkl [mailto:hm@hmerkl.com]
>> Sent: 11 November 2010 21:53
>> To: lucene-net-dev@lucene.apache.org
>> Subject: Re: Lucere project announcement
>>
>> Keep in mind that Java Lucene is being developed actively. Once you
>> start to optimize for .NET, it will become harder and harder to keep
>> up with future Java Lucene development.
>>
>> Whats does MPS do that may be useful for Lucene.NET?
>>
>> On Thu, Nov 11, 2010 at 14:54, Karell Ste-Marie <stemarie@brain-bank.com> wrote:
>> > I have done no other past contribution other than use the product,
>> >
>> > Can I be reminded, once again, why we don't use the .NET Optimized
>> > approaches instead of doing a straight code-code port?
>> >
>> > I understand that the whole purpose of the project is to be a Lucene
>> > port to .NET, but should we not at some point in time optimize more for
>> > .NET than just continue to try and port more Java to .NET code? From
>> > Scratch? Each and every version?
>> >
>> > It seems to be that if that is the approach then perhaps it would be
>> > time better spent to look into a tool such as MPS
>> > (http://www.jetbrains.com/mps/) and then use the source java language
>> > through this which would product .NET code on the other side.
>> >
>> > Or perhaps I've just managed to place a size-12 foot in my mouth because
>> > the current process is actually almost exactly this today?
>> >
>> > Comments welcome...
>> >
>> >
>> >
>> > Karell Ste-Marie
>> > C.I.O. - BrainBank Inc
>> > (514) 636-6655
>> >
>>
>>
>> **********************************************************************
>> --=Disclaimer=--
>> This communication is to be treated as confidential and the information contained
in it may not be used or disclosed except for the purpose for which it has been sent. If you
have received this communication in error, please destroy it immediately and notify postmaster@palmerharvey.co.uk.
Any defamatory statements or infringements of copyright or licenses by employees of Palmer
& Harvey McLane Limited are contrary to company policy. The company will not accept any
liability in respect of such a communication. Computer viruses can be transmitted by email.
The recipient should check this email and any attachments for the presence of viruses. Palmer
& Harvey McLane Limited accepts no liability for any damage caused by any virus transmitted
by this email.
>>
>> Palmer & Harvey McLane Limited.
>> Company registered in England & Wales. Regd. No. 1874153.
>> Regd Office P&H House, Davigdor Road, Hove, East Sussex, BN3 1RE.
>> **********************************************************************
>

Mime
View raw message