Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of casperone@caspershouse.com
 designates 64.79.170.151 as permitted sender)
From: "Nicholas Paldino [.NET/C# MVP]" <casperOne@caspershouse.com>
To: <lucene-net-dev@lucene.apache.org>
Cc: <dev@lucene.apache.org>
References: <COL109-DS71F03D96FDE61952EDF75E4320@phx.gbl>
 <SNT144-ds18593C5379550CFD8D8FC1D2320@phx.gbl>
 <AANLkTim0z3F+Z60-adsovaozyN0-Z4KP-RDEb4C0qdEq@mail.gmail.com>
 <AANLkTik6bdm_0rZoNhHqBcMfh2WstSLsX+Q+93jM1iaf@mail.gmail.com>
 <AANLkTimr5r4MBOoJ9LxjnZxj4w8VOSZfvQjL24e80qGr@mail.gmail.com>
 <0683F6EC5D57564184EF0EC1807BAA7D9AEB38@exchange.brainbankinc.com>
 <AANLkTinXS4SXzgVWeNnZHJ7_=tfUQ9VDpbgheeb5LXAN@mail.gmail.com>
 <70F57422AF52CB43AF1CF9FC49F3CC8D2D0567BB30@HO-NT-IS.palmerharvey.co.uk>
In-Reply-To: 
 <70F57422AF52CB43AF1CF9FC49F3CC8D2D0567BB30@HO-NT-IS.palmerharvey.co.uk>
Subject: RE: Lucene project announcement
Date: Fri, 12 Nov 2010 10:36:17 -0500
Message-ID: <01a201cb827f$5bfd3750$13f7a5f0$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AcuB7ZZO7+6uliocQz2jVQn/8dpecgAUlnfwAAoYWtA=
Content-Language: en-us

Paul, et al,

	Paul, God bless you.  This is probably the most rational, practical
perspective I've seen on the whole matter since the debacle started.

	While Lucene started off as a Java project, it's massive success
indicates that the concepts around it are very desirable by developers in
other technologies, and that the Java product isn't being translated well
into those technology stacks.

	That's not a slight against those who have contributed to this point
to try and keep the .NET version in line with the Java one (despite me
thinking that the actual approach to doing so is a horribly misguided
approach).

	That said, there should be a serious conversation with the
Java-version folk about making this happen.  How can Lucene be
abstracted/standardized in a non-technology-stack-specific way that other
technology stacks can create implementations against that
abstraction/standard.

	Is it too much to ask of the Java folk?  Perhaps.  After all, they
haven't done it yet and it doesn't seem like they see the need for this.
This isn't an unjustified position; that project has a massive user base and
success which creates massive responsibilities to the project that must be
fulfilled.

	If such a thing proceeds, this is what I'd like to see in such an
abstraction:

- Technology-agnostic concepts used, down to the class level:
	- Classes might be the one exception, they are near universal.
However, this could be something like "entity"
	- Properties - Java doesn't have properties, they have a property
convention.  .NET has the concept of a property, which translates to a named
getter and/or setter which can execute additional code on either in addition
to the assignment.
	- Fields - Raw exposed data points.  Whether or not these ^should^
be used is a different story, but there are some places where they are used
so a definition is needed.
	- Methods - Functions/methods, whatever you want to call them, we
all know what they are.
	- In the end, the names are not important as much as the
abstractions are, I think we all have an idea on what they are.
- Right now, I don't have a problem with a class-by-class mapping, but over
time, whether or not class design was done to suit the technology should be
addressed, and ultimately abstracted out if this is the case.
- Things like ^what^ is returned from methods or internal constructs that
are used to make guarantees about behavior and the like should be abstracted
out.  For example, in Lucene.NET we have the following (in order to maintain
a line-by-line port in most cases):
	- A custom implementation of ReaderWriterLock.  There's no reason
for something like this. 
	- Accepting and returning arrays even when the elements in the
arrays are read only.  In this case, there should be hard definitions as to
whether or not an IEnumerable would be better, since .NET has such great
support for deferred execution now.  Of course, if you ^need^ a materialized
list at some point, then an array is fine, but I imagine there are ^many^
places where deferred execution would be a huge boon.
	- Transactional behavior on IndexWriter - I'd love to see this
interact with the Transaction framework that was put in with .NET 2.0.

	I don't expect any abstraction that comes out (if one does) to
follow the above, it's just the things that stick out to me initially.

	Moving on to other issues (the Java Lucene folk can tune out here if
they wish, but feel free to read on!).  First, I've seen others on this list
express a desire to make Lucene.NET more ".NET friendly", on this point, I
can't agree more.

	However, there is massive disparity on what people consider ".NET
friendly"; does it mean wrappers around existing code, better use of .NET
technologies to implement internal functionality, or ".NETifying" things
like properties and the like?  All of those suggestions (and some others I'm
sure) have been posted at one point or another.

	If Paul's idea of a Lucene "standard" was realized, then all of this
becomes a moot point.  For those that say "the Java version is the
standard", re-read the fourth paragraph, the part about technology-agnostic.

	Now, while I don't feel my opinion about whether or not it is a good
idea for people to start their own projects to realize a their vision of a
more ".NET friendly" version of Lucene for .NET is relevant, I will wish
them well.  

	However what is saddening is the feedback that I've seen from people
on this list and in others projects workspaces towards those projects which
are.  NO ONE has the right to say "you should not do that"; if that person
wants to head up that project, so be it, they are moving in the direction
their conscience/heart/mind tells them to go.  Just because you don't agree
with it to be the best step forward doesn't mean they have earned your
indignation.

	It's another thing altogether to say "hey, ^would you^ consider
doing the work here, as we could use your help", or something along those
lines, the key word being "would".  That's a request, "you should" is a
demand.

	Unfortunately, that's not what is happening in and out of the list
and it's behavior that I hope is curbed immediately.

		- Nick

-----Original Message-----
From: Paul Hadfield [mailto:Paul.Hadfield@palmerharvey.co.uk] 
Sent: Friday, November 12, 2010 3:14 AM
To: lucene-net-dev@lucene.apache.org
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.
**********************************************************************


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