You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com> on 2010/11/12 16:36:17 UTC
RE: Lucene project announcement
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 <st...@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
Re: Lucene project announcement
Posted by Grant Ingersoll <gs...@apache.org>.
On Nov 17, 2010, at 3:16 PM, Granroth, Neal V. wrote:
> Is Java Lucene "grown up" ? Look at how much discussion it took to determine how to get Java out of the name :)
Neal, that discussion is exactly how a well-functioning project should work at the ASF. Things are discussed and then a decision is made. If consensus can't be reached, then the issue is dropped until it can be reworked. It's not always the best way of doing things because it can be slow at times, but it is how things work at the ASF when it comes to projects. There is no "King" here who just gets to decide by fiat, so the community had to be asked.
-Grant
Re: Lucene project announcement
Posted by Grant Ingersoll <gs...@apache.org>.
On Nov 17, 2010, at 3:16 PM, Granroth, Neal V. wrote:
> Is Java Lucene "grown up" ? Look at how much discussion it took to determine how to get Java out of the name :)
Neal, that discussion is exactly how a well-functioning project should work at the ASF. Things are discussed and then a decision is made. If consensus can't be reached, then the issue is dropped until it can be reworked. It's not always the best way of doing things because it can be slow at times, but it is how things work at the ASF when it comes to projects. There is no "King" here who just gets to decide by fiat, so the community had to be asked.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene project announcement
Posted by Peter Mateja <pe...@gmail.com>.
Karell,
This is probably drifting way too much off topic, but you could consider
using index sharding by document hashing, with multiple cloud drives to take
advantage of multiple, simultaneous writers, and a MultiSearcher to
aggregate search results across all indices (with the potential deal breaker
that TFIDF would be isolated to each individual index, possibly affecting
your relevance scores.) Of course, this all depends on the profile of what
you're trying to accomplish.
Peter Mateja
peter.mateja@gmail.com
On Thu, Nov 18, 2010 at 1:28 PM, Karell Ste-Marie
<st...@brain-bank.com>wrote:
> Alex,
>
> I stand corrected and offer my appologies - Lucene.NET will run on Azure:
>
> http://social.msdn.microsoft.com/Forums/en/windowsazure/thread/eefa15f3-fef3-4ade-bc3a-ec7fb8e137d9
> It's not elegant but it will work using an Azure drive (equivalent of say a
> filesystem drive)
>
> My claim was based on the outdated fact that when we started using
> Lucene.NET a few years back it would need to create temporary files before
> inserting them into the indexes. It seems that this is now either no longer
> a problem or never was with Azure out of CTP.
>
> I will say that it seems that while it does work, only 1 Azure node may use
> an IndexWriter at any given time which means that only one node may gain
> write access at any time. An Azure Cloud Drive is only even accessible by 1
> worker process at a time since the Azure infrastructure will switch the
> "shared drive" to a readonly mode to other nodes. Therefore if you have say
> 2 applications using Lucene.NET at the same time, they will not be able to
> update it unless you place Lucene.NET on say a central node which the other
> 2 nodes will then access (client/server model). This is not a Lucene.NET
> limitation at this point, this is an Azure Drive limitation - however the
> fact that Lucene.NET needs the filesystem forces this limitation upon us.
>
>
>
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
>
>
> -----Original Message-----
> From: Alex Thompson [mailto:pierogitus@hotmail.com]
> Sent: Thursday, November 18, 2010 1:20 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> Karell,
> What would be the problem with Lucene.Net in Azure?
>
> -----Original Message-----
> From: Karell Ste-Marie [mailto:stemarie@brain-bank.com]
> Sent: Thursday, November 18, 2010 6:01 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> I'm forced politely disagree with some of these thoughts, let me explain
> why:
>
> I order for this technique to be successful it seems that there is as much
> work being poured into the porting technique as there is with the port
> itself. To my point of view it does seem like this is double the work for
> benefits that are perhaps not as good as they could be (I am not saying in
> any way that Lucene.NET today is not good, it is quite good and is the
> results of great efforts from a lot of very dedicated people) since it
> follows a java-style design which is great of the java world, but perhaps
> not always optimal for the C# world. The project should be doing one thing,
> either:
> A) make a great Java to C# porting tool
> B) make a great search engine in C#
>
> As an example, it would be a hair-pulling experience to take Lucene.NET as
> it is today and use it on Microsoft Azure, an environment that is
> specifically designed for .NET applications.
>
> As I said before, besides using Lucene.NET itself I haven't contributed
> much and only in discussions - I haven't committed any code. However I will
> say this: I personally don't know nor care about the Java language just as
> I'm sure many of you don't care about Prolog. In order to help out, I feel
> that I need to be able to read and understand the Lucene version in order to
> make the same stuff happen in the Lucene.NET version. This means I have to
> be both a Java and C# developer at the same time?
>
> Mathematicians have been using math to explain algorithms for years, it is
> a universal language that is (to different levels) understood by all.
>
> How those functional algorithms are implemented in a imperative language
> makes no difference, so long as they are implemented and produce the
> intended result.
>
> I think that in the end, there should be at least 3 projects for Lucene:
> 1. The Lucene algorithms, in a platform-neutral language - let the search
> engine gurus implement how this should be done without having to worry about
> imperative programming and the hacks to get there - either a compiler or a
> manual model would be used to implement these algorithms 2. Lucene -
> Architecture of the project(s) - perhaps a lot of UML here in a format where
> it can be fed to quickly produce skeleton files 3.x. Lucene -
> language-specific versions
>
> As Grant points out it is up to the community to make a decision, then
> let's all get together and see if collectively a decision can be made.
>
> And for the record, I personally think that when an open source project has
> 3+ ports to the same language - there is a problem. What that problem is
> however, I won't venture in taking any guesses.
>
> I make these comments for the good of the project(s) and it is in no way my
> intention to offend anyone and I salute all work and effort done thus far,
> we would not be here were it not for everyone involved.
>
>
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
>
> -----Original Message-----
> From: Alex Thompson [mailto:pierogitus@hotmail.com]
> Sent: Thursday, November 18, 2010 3:58 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> I don't think Lucene.Net staying a line-by-line port is craziness. We're
> not saying that Lucene.Net is the one true implementation and there can be
> no others. I see Lucene.Net as part of a spectrum of solutions.
>
> On one end of the spectrum is IKVM. If you want all the java lucene
> features immediately and the constraints of IKVM work for your scenario then
> great, off you go.
> Then there is Lucene.Net. This is good if IKVM doesn't work for you, you
> want short lag time behind java lucene (yes this needs improvement but we're
> working on it), and ability to read java lucene books/examples and apply
> that relatively seamlessly to your .NET code.
> Then on the other end of the spectrum is the forks
> (wrapper/extension/refactor etc.) that try to make things ideal for the .NET
> world.
>
> I think it's clear there is interest and support for both Lucene.Net and
> the forks. They should both exist and be complimentary, not competitive. The
> forks provide greater flexibility and greater exposure so more users and
> contributors can get involved. Lucene.Net provides the benefits listed above
> and provides an avenue for features to trickle down from java lucene to the
> forks.
>
> So bottom line there is no one-size-fits-all implementation. Lucene.Net (as
> a line-by-line) provides good value to a significant user base and (assuming
> we can optimize the porting) takes relatively little effort, so it is a
> useful part of the spectrum.
>
> Alex
>
> -----Original Message-----
> From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
> Sent: Wednesday, November 17, 2010 5:06 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> Dear All,
>
> I have not yet spoken up on this issue yet but I felt that I could not sit
> in silence any more.
>
> I completely understand the stand point of the current development team and
> agree with the goals that they are setting out to achieve.
>
> Keep this index format compatible with the java version: (check great
> work)
>
> Ensure that an search on a .net version will return the exact same results
> as the java version: (check great work)
>
> But,
>
> This is where the sense seems to end. The "it must be a direct port of
> java stance" is completely craziness.
>
> I am not taking about the use of java conventions, I do not care if a have
> to get a value using something with a prefix of "get", I am talking about
> not making the best use of the tool at hand in this case .NET
>
> There also a clear indication that community (maybe just the vocal ones)
> is saying we want to help be feel we can't or are not inclined to.
>
> Open Source software is about enjoyment and a project that basically says
> if you want to help just translate this code file from java to c#.
>
> Was this not a punishment at school? Translate this passage from Latin to
> English during your break time!
>
> This whole discussion started because the lucence.net project made an
> announcement that we need help, it is not working. It now appears that we
> are going to continue to carry on using the same model, isn't the definition
> of insanity "continuing to do the same thing and expect a different result".
>
> If you are going to be getting an automated tool to do the work great, is a
> community even need? I doubt there will be much for anyone to get involved
> with, except fixing api conflicts between nunit and junit which can probably
> be scripted anyway.
>
> I have seen several people rush out and create their own forks with big
> promises (I know one of them is even being backed by codeproject.com)
> would it not be better to try to channel all of the energy of these people
> on to a branch, homed within apache which is the best place for it and see
> what they come up with?
>
> It is a no lose situation, the current trunk will continue as is but
> something great may appear that everyone is happy with and end this unrest.
>
> Before everyone shouts that people should be putting their efforts into the
> current truck version, it is just not going to happen. You cannot jump up
> and down and say that we are in charge, you must commit our way (it says so
> on the web page) or your energy is not welcome.
>
> I reality, watching the current events unfold, I cannot see much changing.
> Maybe one or two new committers but most people will just wait for the new
> automated tool to get setup, the java guys to fix the bugs and the tool to
> keep the versions up today or the current committers get really "pissed off"
> at continuingly coming under fire and give up (worse outcome possible).
>
> Having said all of that, I just want to say thank you to all of the
> lucence.net committer that have got us to this point. Just should be proud
> of what you have achieved and that actually do have a community that wants
> to see the project continue.
>
> Anyway just how I see things.
>
> Thanks,
>
> Andrew
>
>
>
RE: Lucene project announcement
Posted by Karell Ste-Marie <st...@brain-bank.com>.
Alex,
I stand corrected and offer my appologies - Lucene.NET will run on Azure:
http://social.msdn.microsoft.com/Forums/en/windowsazure/thread/eefa15f3-fef3-4ade-bc3a-ec7fb8e137d9
It's not elegant but it will work using an Azure drive (equivalent of say a filesystem drive)
My claim was based on the outdated fact that when we started using Lucene.NET a few years back it would need to create temporary files before inserting them into the indexes. It seems that this is now either no longer a problem or never was with Azure out of CTP.
I will say that it seems that while it does work, only 1 Azure node may use an IndexWriter at any given time which means that only one node may gain write access at any time. An Azure Cloud Drive is only even accessible by 1 worker process at a time since the Azure infrastructure will switch the "shared drive" to a readonly mode to other nodes. Therefore if you have say 2 applications using Lucene.NET at the same time, they will not be able to update it unless you place Lucene.NET on say a central node which the other 2 nodes will then access (client/server model). This is not a Lucene.NET limitation at this point, this is an Azure Drive limitation - however the fact that Lucene.NET needs the filesystem forces this limitation upon us.
Karell Ste-Marie
C.I.O. - BrainBank Inc
-----Original Message-----
From: Alex Thompson [mailto:pierogitus@hotmail.com]
Sent: Thursday, November 18, 2010 1:20 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
Karell,
What would be the problem with Lucene.Net in Azure?
-----Original Message-----
From: Karell Ste-Marie [mailto:stemarie@brain-bank.com]
Sent: Thursday, November 18, 2010 6:01 AM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
I'm forced politely disagree with some of these thoughts, let me explain why:
I order for this technique to be successful it seems that there is as much work being poured into the porting technique as there is with the port itself. To my point of view it does seem like this is double the work for benefits that are perhaps not as good as they could be (I am not saying in any way that Lucene.NET today is not good, it is quite good and is the results of great efforts from a lot of very dedicated people) since it follows a java-style design which is great of the java world, but perhaps not always optimal for the C# world. The project should be doing one thing, either:
A) make a great Java to C# porting tool
B) make a great search engine in C#
As an example, it would be a hair-pulling experience to take Lucene.NET as it is today and use it on Microsoft Azure, an environment that is specifically designed for .NET applications.
As I said before, besides using Lucene.NET itself I haven't contributed much and only in discussions - I haven't committed any code. However I will say this: I personally don't know nor care about the Java language just as I'm sure many of you don't care about Prolog. In order to help out, I feel that I need to be able to read and understand the Lucene version in order to make the same stuff happen in the Lucene.NET version. This means I have to be both a Java and C# developer at the same time?
Mathematicians have been using math to explain algorithms for years, it is a universal language that is (to different levels) understood by all.
How those functional algorithms are implemented in a imperative language makes no difference, so long as they are implemented and produce the intended result.
I think that in the end, there should be at least 3 projects for Lucene:
1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files 3.x. Lucene - language-specific versions
As Grant points out it is up to the community to make a decision, then let's all get together and see if collectively a decision can be made.
And for the record, I personally think that when an open source project has 3+ ports to the same language - there is a problem. What that problem is however, I won't venture in taking any guesses.
I make these comments for the good of the project(s) and it is in no way my intention to offend anyone and I salute all work and effort done thus far, we would not be here were it not for everyone involved.
Karell Ste-Marie
C.I.O. - BrainBank Inc
-----Original Message-----
From: Alex Thompson [mailto:pierogitus@hotmail.com]
Sent: Thursday, November 18, 2010 3:58 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as part of a spectrum of solutions.
On one end of the spectrum is IKVM. If you want all the java lucene features immediately and the constraints of IKVM work for your scenario then great, off you go.
Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag time behind java lucene (yes this needs improvement but we're working on it), and ability to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.) that try to make things ideal for the .NET world.
I think it's clear there is interest and support for both Lucene.Net and the forks. They should both exist and be complimentary, not competitive. The forks provide greater flexibility and greater exposure so more users and contributors can get involved. Lucene.Net provides the benefits listed above and provides an avenue for features to trickle down from java lucene to the forks.
So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line) provides good value to a significant user base and (assuming we can optimize the porting) takes relatively little effort, so it is a useful part of the spectrum.
Alex
-----Original Message-----
From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
Sent: Wednesday, November 17, 2010 5:06 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
Dear All,
I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
Keep this index format compatible with the java version: (check great work)
Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
But,
This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
Was this not a punishment at school? Translate this passage from Latin to English during your break time!
This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
Anyway just how I see things.
Thanks,
Andrew
RE: Lucene project announcement
Posted by Alex Thompson <pi...@hotmail.com>.
Karell,
What would be the problem with Lucene.Net in Azure?
-----Original Message-----
From: Karell Ste-Marie [mailto:stemarie@brain-bank.com]
Sent: Thursday, November 18, 2010 6:01 AM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
I'm forced politely disagree with some of these thoughts, let me explain why:
I order for this technique to be successful it seems that there is as much work being poured into the porting technique as there is with the port itself. To my point of view it does seem like this is double the work for benefits that are perhaps not as good as they could be (I am not saying in any way that Lucene.NET today is not good, it is quite good and is the results of great efforts from a lot of very dedicated people) since it follows a java-style design which is great of the java world, but perhaps not always optimal for the C# world. The project should be doing one thing, either:
A) make a great Java to C# porting tool
B) make a great search engine in C#
As an example, it would be a hair-pulling experience to take Lucene.NET as it is today and use it on Microsoft Azure, an environment that is specifically designed for .NET applications.
As I said before, besides using Lucene.NET itself I haven't contributed much and only in discussions - I haven't committed any code. However I will say this: I personally don't know nor care about the Java language just as I'm sure many of you don't care about Prolog. In order to help out, I feel that I need to be able to read and understand the Lucene version in order to make the same stuff happen in the Lucene.NET version. This means I have to be both a Java and C# developer at the same time?
Mathematicians have been using math to explain algorithms for years, it is a universal language that is (to different levels) understood by all.
How those functional algorithms are implemented in a imperative language makes no difference, so long as they are implemented and produce the intended result.
I think that in the end, there should be at least 3 projects for Lucene:
1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files 3.x. Lucene - language-specific versions
As Grant points out it is up to the community to make a decision, then let's all get together and see if collectively a decision can be made.
And for the record, I personally think that when an open source project has 3+ ports to the same language - there is a problem. What that problem is however, I won't venture in taking any guesses.
I make these comments for the good of the project(s) and it is in no way my intention to offend anyone and I salute all work and effort done thus far, we would not be here were it not for everyone involved.
Karell Ste-Marie
C.I.O. - BrainBank Inc
-----Original Message-----
From: Alex Thompson [mailto:pierogitus@hotmail.com]
Sent: Thursday, November 18, 2010 3:58 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as part of a spectrum of solutions.
On one end of the spectrum is IKVM. If you want all the java lucene features immediately and the constraints of IKVM work for your scenario then great, off you go.
Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag time behind java lucene (yes this needs improvement but we're working on it), and ability to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.) that try to make things ideal for the .NET world.
I think it's clear there is interest and support for both Lucene.Net and the forks. They should both exist and be complimentary, not competitive. The forks provide greater flexibility and greater exposure so more users and contributors can get involved. Lucene.Net provides the benefits listed above and provides an avenue for features to trickle down from java lucene to the forks.
So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line) provides good value to a significant user base and (assuming we can optimize the porting) takes relatively little effort, so it is a useful part of the spectrum.
Alex
-----Original Message-----
From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
Sent: Wednesday, November 17, 2010 5:06 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
Dear All,
I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
Keep this index format compatible with the java version: (check great work)
Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
But,
This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
Was this not a punishment at school? Translate this passage from Latin to English during your break time!
This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
Anyway just how I see things.
Thanks,
Andrew
Re: Lucene project announcement
Posted by Peter Karich <pe...@yahoo.de>.
> A) make a great Java to C# porting tool
db4o has already something like this, I think.
maybe the guys from db4o would give lucene committers a license?
or would it be bad to rely on none free tools like this?
or maybe there is already an equivalent tool?
Regards,
Peter.
> I'm forced politely disagree with some of these thoughts, let me explain why:
>
> I order for this technique to be successful it seems that there is as much work being poured into the porting technique as there is with the port itself. To my point of view it does seem like this is double the work for benefits that are perhaps not as good as they could be (I am not saying in any way that Lucene.NET today is not good, it is quite good and is the results of great efforts from a lot of very dedicated people) since it follows a java-style design which is great of the java world, but perhaps not always optimal for the C# world. The project should be doing one thing, either:
> A) make a great Java to C# porting tool
> B) make a great search engine in C#
>
> As an example, it would be a hair-pulling experience to take Lucene.NET as it is today and use it on Microsoft Azure, an environment that is specifically designed for .NET applications.
>
> As I said before, besides using Lucene.NET itself I haven't contributed much and only in discussions - I haven't committed any code. However I will say this: I personally don't know nor care about the Java language just as I'm sure many of you don't care about Prolog. In order to help out, I feel that I need to be able to read and understand the Lucene version in order to make the same stuff happen in the Lucene.NET version. This means I have to be both a Java and C# developer at the same time?
>
> Mathematicians have been using math to explain algorithms for years, it is a universal language that is (to different levels) understood by all.
>
> How those functional algorithms are implemented in a imperative language makes no difference, so long as they are implemented and produce the intended result.
>
> I think that in the end, there should be at least 3 projects for Lucene:
> 1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms
> 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files
> 3.x. Lucene - language-specific versions
>
> As Grant points out it is up to the community to make a decision, then let's all get together and see if collectively a decision can be made.
>
> And for the record, I personally think that when an open source project has 3+ ports to the same language - there is a problem. What that problem is however, I won't venture in taking any guesses.
>
> I make these comments for the good of the project(s) and it is in no way my intention to offend anyone and I salute all work and effort done thus far, we would not be here were it not for everyone involved.
>
>
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
>
> -----Original Message-----
> From: Alex Thompson [mailto:pierogitus@hotmail.com]
> Sent: Thursday, November 18, 2010 3:58 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as part of a spectrum of solutions.
>
> On one end of the spectrum is IKVM. If you want all the java lucene features immediately and the constraints of IKVM work for your scenario then great, off you go.
> Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag time behind java lucene (yes this needs improvement but we're working on it), and ability to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
> Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.) that try to make things ideal for the .NET world.
>
> I think it's clear there is interest and support for both Lucene.Net and the forks. They should both exist and be complimentary, not competitive. The forks provide greater flexibility and greater exposure so more users and contributors can get involved. Lucene.Net provides the benefits listed above and provides an avenue for features to trickle down from java lucene to the forks.
>
> So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line) provides good value to a significant user base and (assuming we can optimize the porting) takes relatively little effort, so it is a useful part of the spectrum.
>
> Alex
>
> -----Original Message-----
> From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
> Sent: Wednesday, November 17, 2010 5:06 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> Dear All,
>
> I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
>
> I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
>
> Keep this index format compatible with the java version: (check great work)
>
> Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
>
> But,
>
> This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
>
> I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
>
> There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
>
> Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
>
> Was this not a punishment at school? Translate this passage from Latin to English during your break time!
>
> This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
>
> If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
>
> I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
>
> It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
>
> Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
>
> I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
>
> Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
>
> Anyway just how I see things.
>
> Thanks,
>
> Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Lucene project announcement
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
On Thu, 2010-11-18 at 15:00 +0100, Karell Ste-Marie wrote:
> I think that in the end, there should be at least 3 projects for Lucene:
> 1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms
> 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files
> 3.x. Lucene - language-specific versions
Speaking as a computer scientist, this looks like a text book example of
a solid multi-level development workflow. Perfect for a well-defined
hierarchy of dependable workers.
Speaking as a rookie contributor to Lucene (I wrote some code for
https://issues.apache.org/jira/browse/LUCENE-1990), I very much doubt
that I would have contributed if that workflow was in place. Let me try
and explain why.
LUCENE-1990 was an isolated and fairly simple task: Do some bit fiddling
to pack integers and perform some tests to find the best solution. It
was fun to do and I think the implementation works well (no conditionals
or heavy math in the core get/set methods) and should work just about
the same in other languages as it is nearly pure math and arrays.
Theoretically the easily abstractable nature of this plays very well
with the top-down approach that you present. The problem is that step 1
(the algorithm in the platform-neutral language) requires me to learn
that language and learn the extra steps necessary to contribute in such
manner. I also need to know enough about step 2 to decide whether I had
to update some diagrams and in general doing work that I find boring.
I can see that you are "C.I.O. - BrainBank Inc" and a quick look at your
website tells me that handling complex multi-level integration is second
nature to you.
I am a bear of very little brain and organizations and politics bother
me. Hacker's Delight is 7 cm from my left hand (I measured with my
multitool): I'll come up with algorithms, I'll discuss them, I'll
implement them, I'll test them, I'll even write JavaDocs, I'll do it all
for free - although most of it in on the company dime. And I'll have fun
doing it. Ask me to step outside of my coding comfort zone and the
chance of me volunteering will drop sharply.
My message is that a fundamental change of participation requirements
for the Lucene project means that some participants will not play along
anymore and other people will be attracted to the project. This might
turn out to be a very good thing for Lucene or it might seriously hamper
development. My gut feeling says the latter, but then again, I'm biased
by being firmly in the low-level group.
Regards,
Toke Eskildsen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene project announcement
Posted by Hans Merkl <hm...@hmerkl.com>.
I don't really understand why so many people seem to have a problem with the
interface of Lucene.NET. From my experience it's straightforward and easy to
use. Sure, it doesn't support LINQ and doesn't have properties but to me
this is just syntactic sugar. And I like the fact that I can use sample code
from books like "Lucene in Action" virtually unmodified.
RE: Lucene project announcement
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
On Thu, 2010-11-18 at 15:00 +0100, Karell Ste-Marie wrote:
> I think that in the end, there should be at least 3 projects for Lucene:
> 1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms
> 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files
> 3.x. Lucene - language-specific versions
Speaking as a computer scientist, this looks like a text book example of
a solid multi-level development workflow. Perfect for a well-defined
hierarchy of dependable workers.
Speaking as a rookie contributor to Lucene (I wrote some code for
https://issues.apache.org/jira/browse/LUCENE-1990), I very much doubt
that I would have contributed if that workflow was in place. Let me try
and explain why.
LUCENE-1990 was an isolated and fairly simple task: Do some bit fiddling
to pack integers and perform some tests to find the best solution. It
was fun to do and I think the implementation works well (no conditionals
or heavy math in the core get/set methods) and should work just about
the same in other languages as it is nearly pure math and arrays.
Theoretically the easily abstractable nature of this plays very well
with the top-down approach that you present. The problem is that step 1
(the algorithm in the platform-neutral language) requires me to learn
that language and learn the extra steps necessary to contribute in such
manner. I also need to know enough about step 2 to decide whether I had
to update some diagrams and in general doing work that I find boring.
I can see that you are "C.I.O. - BrainBank Inc" and a quick look at your
website tells me that handling complex multi-level integration is second
nature to you.
I am a bear of very little brain and organizations and politics bother
me. Hacker's Delight is 7 cm from my left hand (I measured with my
multitool): I'll come up with algorithms, I'll discuss them, I'll
implement them, I'll test them, I'll even write JavaDocs, I'll do it all
for free - although most of it in on the company dime. And I'll have fun
doing it. Ask me to step outside of my coding comfort zone and the
chance of me volunteering will drop sharply.
My message is that a fundamental change of participation requirements
for the Lucene project means that some participants will not play along
anymore and other people will be attracted to the project. This might
turn out to be a very good thing for Lucene or it might seriously hamper
development. My gut feeling says the latter, but then again, I'm biased
by being firmly in the low-level group.
Regards,
Toke Eskildsen
RE: Lucene project announcement
Posted by Karell Ste-Marie <st...@brain-bank.com>.
I'm forced politely disagree with some of these thoughts, let me explain why:
I order for this technique to be successful it seems that there is as much work being poured into the porting technique as there is with the port itself. To my point of view it does seem like this is double the work for benefits that are perhaps not as good as they could be (I am not saying in any way that Lucene.NET today is not good, it is quite good and is the results of great efforts from a lot of very dedicated people) since it follows a java-style design which is great of the java world, but perhaps not always optimal for the C# world. The project should be doing one thing, either:
A) make a great Java to C# porting tool
B) make a great search engine in C#
As an example, it would be a hair-pulling experience to take Lucene.NET as it is today and use it on Microsoft Azure, an environment that is specifically designed for .NET applications.
As I said before, besides using Lucene.NET itself I haven't contributed much and only in discussions - I haven't committed any code. However I will say this: I personally don't know nor care about the Java language just as I'm sure many of you don't care about Prolog. In order to help out, I feel that I need to be able to read and understand the Lucene version in order to make the same stuff happen in the Lucene.NET version. This means I have to be both a Java and C# developer at the same time?
Mathematicians have been using math to explain algorithms for years, it is a universal language that is (to different levels) understood by all.
How those functional algorithms are implemented in a imperative language makes no difference, so long as they are implemented and produce the intended result.
I think that in the end, there should be at least 3 projects for Lucene:
1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms
2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files
3.x. Lucene - language-specific versions
As Grant points out it is up to the community to make a decision, then let's all get together and see if collectively a decision can be made.
And for the record, I personally think that when an open source project has 3+ ports to the same language - there is a problem. What that problem is however, I won't venture in taking any guesses.
I make these comments for the good of the project(s) and it is in no way my intention to offend anyone and I salute all work and effort done thus far, we would not be here were it not for everyone involved.
Karell Ste-Marie
C.I.O. - BrainBank Inc
-----Original Message-----
From: Alex Thompson [mailto:pierogitus@hotmail.com]
Sent: Thursday, November 18, 2010 3:58 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as part of a spectrum of solutions.
On one end of the spectrum is IKVM. If you want all the java lucene features immediately and the constraints of IKVM work for your scenario then great, off you go.
Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag time behind java lucene (yes this needs improvement but we're working on it), and ability to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.) that try to make things ideal for the .NET world.
I think it's clear there is interest and support for both Lucene.Net and the forks. They should both exist and be complimentary, not competitive. The forks provide greater flexibility and greater exposure so more users and contributors can get involved. Lucene.Net provides the benefits listed above and provides an avenue for features to trickle down from java lucene to the forks.
So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line) provides good value to a significant user base and (assuming we can optimize the porting) takes relatively little effort, so it is a useful part of the spectrum.
Alex
-----Original Message-----
From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
Sent: Wednesday, November 17, 2010 5:06 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
Dear All,
I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
Keep this index format compatible with the java version: (check great work)
Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
But,
This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
Was this not a punishment at school? Translate this passage from Latin to English during your break time!
This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
Anyway just how I see things.
Thanks,
Andrew
RE: Lucene project announcement
Posted by Karell Ste-Marie <st...@brain-bank.com>.
I'm forced politely disagree with some of these thoughts, let me explain why:
I order for this technique to be successful it seems that there is as much work being poured into the porting technique as there is with the port itself. To my point of view it does seem like this is double the work for benefits that are perhaps not as good as they could be (I am not saying in any way that Lucene.NET today is not good, it is quite good and is the results of great efforts from a lot of very dedicated people) since it follows a java-style design which is great of the java world, but perhaps not always optimal for the C# world. The project should be doing one thing, either:
A) make a great Java to C# porting tool
B) make a great search engine in C#
As an example, it would be a hair-pulling experience to take Lucene.NET as it is today and use it on Microsoft Azure, an environment that is specifically designed for .NET applications.
As I said before, besides using Lucene.NET itself I haven't contributed much and only in discussions - I haven't committed any code. However I will say this: I personally don't know nor care about the Java language just as I'm sure many of you don't care about Prolog. In order to help out, I feel that I need to be able to read and understand the Lucene version in order to make the same stuff happen in the Lucene.NET version. This means I have to be both a Java and C# developer at the same time?
Mathematicians have been using math to explain algorithms for years, it is a universal language that is (to different levels) understood by all.
How those functional algorithms are implemented in a imperative language makes no difference, so long as they are implemented and produce the intended result.
I think that in the end, there should be at least 3 projects for Lucene:
1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus implement how this should be done without having to worry about imperative programming and the hacks to get there - either a compiler or a manual model would be used to implement these algorithms
2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where it can be fed to quickly produce skeleton files
3.x. Lucene - language-specific versions
As Grant points out it is up to the community to make a decision, then let's all get together and see if collectively a decision can be made.
And for the record, I personally think that when an open source project has 3+ ports to the same language - there is a problem. What that problem is however, I won't venture in taking any guesses.
I make these comments for the good of the project(s) and it is in no way my intention to offend anyone and I salute all work and effort done thus far, we would not be here were it not for everyone involved.
Karell Ste-Marie
C.I.O. - BrainBank Inc
-----Original Message-----
From: Alex Thompson [mailto:pierogitus@hotmail.com]
Sent: Thursday, November 18, 2010 3:58 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as part of a spectrum of solutions.
On one end of the spectrum is IKVM. If you want all the java lucene features immediately and the constraints of IKVM work for your scenario then great, off you go.
Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag time behind java lucene (yes this needs improvement but we're working on it), and ability to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.) that try to make things ideal for the .NET world.
I think it's clear there is interest and support for both Lucene.Net and the forks. They should both exist and be complimentary, not competitive. The forks provide greater flexibility and greater exposure so more users and contributors can get involved. Lucene.Net provides the benefits listed above and provides an avenue for features to trickle down from java lucene to the forks.
So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line) provides good value to a significant user base and (assuming we can optimize the porting) takes relatively little effort, so it is a useful part of the spectrum.
Alex
-----Original Message-----
From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
Sent: Wednesday, November 17, 2010 5:06 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
Dear All,
I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
Keep this index format compatible with the java version: (check great work)
Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
But,
This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
Was this not a punishment at school? Translate this passage from Latin to English during your break time!
This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
Anyway just how I see things.
Thanks,
Andrew
RE: Lucene project announcement
Posted by Alex Thompson <pi...@hotmail.com>.
I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as part of a spectrum of solutions.
On one end of the spectrum is IKVM. If you want all the java lucene features immediately and the constraints of IKVM work for your scenario then great, off you go.
Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag time behind java lucene (yes this needs improvement but we're working on it), and ability to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.) that try to make things ideal for the .NET world.
I think it's clear there is interest and support for both Lucene.Net and the forks. They should both exist and be complimentary, not competitive. The forks provide greater flexibility and greater exposure so more users and contributors can get involved. Lucene.Net provides the benefits listed above and provides an avenue for features to trickle down from java lucene to the forks.
So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line) provides good value to a significant user base and (assuming we can optimize the porting) takes relatively little effort, so it is a useful part of the spectrum.
Alex
-----Original Message-----
From: Andrew Busby [mailto:andrew.busby@aimstrategic.com]
Sent: Wednesday, November 17, 2010 5:06 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: Lucene project announcement
Dear All,
I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
Keep this index format compatible with the java version: (check great work)
Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
But,
This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
Was this not a punishment at school? Translate this passage from Latin to English during your break time!
This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
Anyway just how I see things.
Thanks,
Andrew
-----Original Message-----
From: Troy Howard [mailto:thoward37@gmail.com]
Sent: 17 November 2010 23:35
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: Re: Lucene project announcement
Neal,
As you said, "If you're developing at the concept level the specific language you use becomes unimportant. ".
This is exactly why we feel that working on this in C# is not a problem. We feel that the language should not impede our ability to contribute. If we develop some interesting or valuable concepts in C# those could be ported back to Java for inclusion in the Java implementation of Lucene.
>From an implementation standpoint, we feel that the code should perform and integrate as effectively as possible into the runtime it's in. Unfortunately there's no known software runtime that executes concepts. They execute code written in a specific language. The details of how that code executes and integrates into applications directly effects it's performance and usability.
It's a disservice to the concept of Lucene to translate it literally, if doing so makes it less performant or less usable.
Using human language as an example:
Consider the Chinese name for China:
?? (Zhong Guo)
translated literally it means "Middle Kingdom".
Imagine you were translating and important philosophical document from Chinese to English. Would you translate "Zhong Guo" as "Middle Kingdom" or as "China"?
Suppose someone had asked the original philosopher to write all his ideas in English to start because "English is the language of philosophy.. It's what all the eminent philosophers use". Perhaps he would never contribute his ideas at all, since writing them down in English is too great a barrier. Maybe he would write them down, but write them down in a way which made them seem absurd or have less of an impact.. In other words.. Miss the meaning, even though he'd translated literally.
Either way, it would be less ideal than simply writing them in Chinese to start, as that's what would be most natural for our imaginary philosopher. The burden of translation from Chinese to English could then be performed by an expert in translation, who would, undoubtedly, translate the meaning conceptually, not the words syntactically.
Thanks,
Troy
On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<ne...@thermofisher.com> wrote:
> Is Java Lucene "grown up" ? Look at how much discussion it took to
> determine how to get Java out of the name :)
>
> The discussion about advancing the algorithm in C#/.NET seems to be missing the point. If you're developing at the concept level the specific language you use becomes unimportant. However as most of the concept developers apparently find Java convenient; others wanting to participate at the concept level would find it more beneficial to join that brain-pool instead of diluting the effort by starting up elsewhere.
>
>
> - Neal
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, November 16, 2010 10:55 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> This topic has been coming back again and again which I have tried to
> address multiple times, so let me try again.
>
> 1) Java Lucene started years before the first C# version (4+ years if
> I get my history right), thus it defined and has been the definer of
> the technology and the API. It is the established leader, and
> everyone else is just a follower.
>
> 2) Lucene.Net is no were mature as Java Lucene, never got established
> itself, or had a rich development community -- thus why we are here today.
>
> 3) If and only if, the community of Lucene.Net (or "Lucene" over at
> codeplex.com) manages to proves itself to the level of Java Lucene,
> only then such a community will have the voice to influence folks over
> at Java Lucene. Only then you will see the two community discussing
> search engine vs. port issues or the state of Lucene.Net.
>
> If you look in my previous posts, I have pointed those out. We must first:
>
> 1) Be in par with Java Lucene release and keep up with
> commit-per-commit port.
>
> 2) Prove Lucene.Net is a grownup project with followers and a healthy
> community (just like Java Lucene).
>
> If we don't achieve the above, folks over at Java Lucene will not take
> us seriously, and thus we can't influence them.
>
> -- George
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP]
> [mailto:casperOne@caspershouse.com]
> Sent: Friday, November 12, 2010 10:36 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> 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
> <st...@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.
> **********************************************************************
>
>
>
>
RE: Lucene project announcement
Posted by Andrew Busby <an...@aimstrategic.com>.
Dear All,
I have not yet spoken up on this issue yet but I felt that I could not sit in silence any more.
I completely understand the stand point of the current development team and agree with the goals that they are setting out to achieve.
Keep this index format compatible with the java version: (check great work)
Ensure that an search on a .net version will return the exact same results as the java version: (check great work)
But,
This is where the sense seems to end. The "it must be a direct port of java stance" is completely craziness.
I am not taking about the use of java conventions, I do not care if a have to get a value using something with a prefix of "get", I am talking about not making the best use of the tool at hand in this case .NET
There also a clear indication that community (maybe just the vocal ones) is saying we want to help be feel we can't or are not inclined to.
Open Source software is about enjoyment and a project that basically says if you want to help just translate this code file from java to c#.
Was this not a punishment at school? Translate this passage from Latin to English during your break time!
This whole discussion started because the lucence.net project made an announcement that we need help, it is not working. It now appears that we are going to continue to carry on using the same model, isn't the definition of insanity "continuing to do the same thing and expect a different result".
If you are going to be getting an automated tool to do the work great, is a community even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts between nunit and junit which can probably be scripted anyway.
I have seen several people rush out and create their own forks with big promises (I know one of them is even being backed by codeproject.com) would it not be better to try to channel all of the energy of these people on to a branch, homed within apache which is the best place for it and see what they come up with?
It is a no lose situation, the current trunk will continue as is but something great may appear that everyone is happy with and end this unrest.
Before everyone shouts that people should be putting their efforts into the current truck version, it is just not going to happen. You cannot jump up and down and say that we are in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
I reality, watching the current events unfold, I cannot see much changing. Maybe one or two new committers but most people will just wait for the new automated tool to get setup, the java guys to fix the bugs and the tool to keep the versions up today or the current committers get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
Having said all of that, I just want to say thank you to all of the lucence.net committer that have got us to this point. Just should be proud of what you have achieved and that actually do have a community that wants to see the project continue.
Anyway just how I see things.
Thanks,
Andrew
-----Original Message-----
From: Troy Howard [mailto:thoward37@gmail.com]
Sent: 17 November 2010 23:35
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: Re: Lucene project announcement
Neal,
As you said, "If you're developing at the concept level the specific language you use becomes unimportant. ".
This is exactly why we feel that working on this in C# is not a problem. We feel that the language should not impede our ability to contribute. If we develop some interesting or valuable concepts in C# those could be ported back to Java for inclusion in the Java implementation of Lucene.
>From an implementation standpoint, we feel that the code should perform and integrate as effectively as possible into the runtime it's in. Unfortunately there's no known software runtime that executes concepts. They execute code written in a specific language. The details of how that code executes and integrates into applications directly effects it's performance and usability.
It's a disservice to the concept of Lucene to translate it literally, if doing so makes it less performant or less usable.
Using human language as an example:
Consider the Chinese name for China:
?? (Zhong Guo)
translated literally it means "Middle Kingdom".
Imagine you were translating and important philosophical document from Chinese to English. Would you translate "Zhong Guo" as "Middle Kingdom" or as "China"?
Suppose someone had asked the original philosopher to write all his ideas in English to start because "English is the language of philosophy.. It's what all the eminent philosophers use". Perhaps he would never contribute his ideas at all, since writing them down in English is too great a barrier. Maybe he would write them down, but write them down in a way which made them seem absurd or have less of an impact.. In other words.. Miss the meaning, even though he'd translated literally.
Either way, it would be less ideal than simply writing them in Chinese to start, as that's what would be most natural for our imaginary philosopher. The burden of translation from Chinese to English could then be performed by an expert in translation, who would, undoubtedly, translate the meaning conceptually, not the words syntactically.
Thanks,
Troy
On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<ne...@thermofisher.com> wrote:
> Is Java Lucene "grown up" ? Look at how much discussion it took to
> determine how to get Java out of the name :)
>
> The discussion about advancing the algorithm in C#/.NET seems to be missing the point. If you're developing at the concept level the specific language you use becomes unimportant. However as most of the concept developers apparently find Java convenient; others wanting to participate at the concept level would find it more beneficial to join that brain-pool instead of diluting the effort by starting up elsewhere.
>
>
> - Neal
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, November 16, 2010 10:55 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> This topic has been coming back again and again which I have tried to
> address multiple times, so let me try again.
>
> 1) Java Lucene started years before the first C# version (4+ years if
> I get my history right), thus it defined and has been the definer of
> the technology and the API. It is the established leader, and
> everyone else is just a follower.
>
> 2) Lucene.Net is no were mature as Java Lucene, never got established
> itself, or had a rich development community -- thus why we are here today.
>
> 3) If and only if, the community of Lucene.Net (or "Lucene" over at
> codeplex.com) manages to proves itself to the level of Java Lucene,
> only then such a community will have the voice to influence folks over
> at Java Lucene. Only then you will see the two community discussing
> search engine vs. port issues or the state of Lucene.Net.
>
> If you look in my previous posts, I have pointed those out. We must first:
>
> 1) Be in par with Java Lucene release and keep up with
> commit-per-commit port.
>
> 2) Prove Lucene.Net is a grownup project with followers and a healthy
> community (just like Java Lucene).
>
> If we don't achieve the above, folks over at Java Lucene will not take
> us seriously, and thus we can't influence them.
>
> -- George
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP]
> [mailto:casperOne@caspershouse.com]
> Sent: Friday, November 12, 2010 10:36 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> 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
> <st...@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.
> **********************************************************************
>
>
>
>
Re: Lucene project announcement
Posted by Troy Howard <th...@gmail.com>.
Neal,
As you said, "If you're developing at the concept level the specific
language you use becomes unimportant. ".
This is exactly why we feel that working on this in C# is not a
problem. We feel that the language should not impede our ability to
contribute. If we develop some interesting or valuable concepts in C#
those could be ported back to Java for inclusion in the Java
implementation of Lucene.
>From an implementation standpoint, we feel that the code should
perform and integrate as effectively as possible into the runtime it's
in. Unfortunately there's no known software runtime that executes
concepts. They execute code written in a specific language. The
details of how that code executes and integrates into applications
directly effects it's performance and usability.
It's a disservice to the concept of Lucene to translate it literally,
if doing so makes it less performant or less usable.
Using human language as an example:
Consider the Chinese name for China:
中国 (Zhong Guo)
translated literally it means "Middle Kingdom".
Imagine you were translating and important philosophical document from
Chinese to English. Would you translate "Zhong Guo" as "Middle
Kingdom" or as "China"?
Suppose someone had asked the original philosopher to write all his
ideas in English to start because "English is the language of
philosophy.. It's what all the eminent philosophers use". Perhaps he
would never contribute his ideas at all, since writing them down in
English is too great a barrier. Maybe he would write them down, but
write them down in a way which made them seem absurd or have less of
an impact.. In other words.. Miss the meaning, even though he'd
translated literally.
Either way, it would be less ideal than simply writing them in Chinese
to start, as that's what would be most natural for our imaginary
philosopher. The burden of translation from Chinese to English could
then be performed by an expert in translation, who would, undoubtedly,
translate the meaning conceptually, not the words syntactically.
Thanks,
Troy
On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<ne...@thermofisher.com> wrote:
> Is Java Lucene "grown up" ? Look at how much discussion it took to determine how to get Java out of the name :)
>
> The discussion about advancing the algorithm in C#/.NET seems to be missing the point. If you're developing at the concept level the specific language you use becomes unimportant. However as most of the concept developers apparently find Java convenient; others wanting to participate at the concept level would find it more beneficial to join that brain-pool instead of diluting the effort by starting up elsewhere.
>
>
> - Neal
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, November 16, 2010 10:55 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> This topic has been coming back again and again which I have tried to
> address multiple times, so let me try again.
>
> 1) Java Lucene started years before the first C# version (4+ years if I get
> my history right), thus it defined and has been the definer of the
> technology and the API. It is the established leader, and everyone else is
> just a follower.
>
> 2) Lucene.Net is no were mature as Java Lucene, never got established
> itself, or had a rich development community -- thus why we are here today.
>
> 3) If and only if, the community of Lucene.Net (or "Lucene" over at
> codeplex.com) manages to proves itself to the level of Java Lucene, only
> then such a community will have the voice to influence folks over at Java
> Lucene. Only then you will see the two community discussing search engine
> vs. port issues or the state of Lucene.Net.
>
> If you look in my previous posts, I have pointed those out. We must first:
>
> 1) Be in par with Java Lucene release and keep up with commit-per-commit
> port.
>
> 2) Prove Lucene.Net is a grownup project with followers and a healthy
> community (just like Java Lucene).
>
> If we don't achieve the above, folks over at Java Lucene will not take us
> seriously, and thus we can't influence them.
>
> -- George
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
> Sent: Friday, November 12, 2010 10:36 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> 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 <st...@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.
> **********************************************************************
>
>
>
>
Re: Lucene project announcement
Posted by Troy Howard <th...@gmail.com>.
Neal,
As you said, "If you're developing at the concept level the specific
language you use becomes unimportant. ".
This is exactly why we feel that working on this in C# is not a
problem. We feel that the language should not impede our ability to
contribute. If we develop some interesting or valuable concepts in C#
those could be ported back to Java for inclusion in the Java
implementation of Lucene.
>From an implementation standpoint, we feel that the code should
perform and integrate as effectively as possible into the runtime it's
in. Unfortunately there's no known software runtime that executes
concepts. They execute code written in a specific language. The
details of how that code executes and integrates into applications
directly effects it's performance and usability.
It's a disservice to the concept of Lucene to translate it literally,
if doing so makes it less performant or less usable.
Using human language as an example:
Consider the Chinese name for China:
中国 (Zhong Guo)
translated literally it means "Middle Kingdom".
Imagine you were translating and important philosophical document from
Chinese to English. Would you translate "Zhong Guo" as "Middle
Kingdom" or as "China"?
Suppose someone had asked the original philosopher to write all his
ideas in English to start because "English is the language of
philosophy.. It's what all the eminent philosophers use". Perhaps he
would never contribute his ideas at all, since writing them down in
English is too great a barrier. Maybe he would write them down, but
write them down in a way which made them seem absurd or have less of
an impact.. In other words.. Miss the meaning, even though he'd
translated literally.
Either way, it would be less ideal than simply writing them in Chinese
to start, as that's what would be most natural for our imaginary
philosopher. The burden of translation from Chinese to English could
then be performed by an expert in translation, who would, undoubtedly,
translate the meaning conceptually, not the words syntactically.
Thanks,
Troy
On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<ne...@thermofisher.com> wrote:
> Is Java Lucene "grown up" ? Look at how much discussion it took to determine how to get Java out of the name :)
>
> The discussion about advancing the algorithm in C#/.NET seems to be missing the point. If you're developing at the concept level the specific language you use becomes unimportant. However as most of the concept developers apparently find Java convenient; others wanting to participate at the concept level would find it more beneficial to join that brain-pool instead of diluting the effort by starting up elsewhere.
>
>
> - Neal
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, November 16, 2010 10:55 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> This topic has been coming back again and again which I have tried to
> address multiple times, so let me try again.
>
> 1) Java Lucene started years before the first C# version (4+ years if I get
> my history right), thus it defined and has been the definer of the
> technology and the API. It is the established leader, and everyone else is
> just a follower.
>
> 2) Lucene.Net is no were mature as Java Lucene, never got established
> itself, or had a rich development community -- thus why we are here today.
>
> 3) If and only if, the community of Lucene.Net (or "Lucene" over at
> codeplex.com) manages to proves itself to the level of Java Lucene, only
> then such a community will have the voice to influence folks over at Java
> Lucene. Only then you will see the two community discussing search engine
> vs. port issues or the state of Lucene.Net.
>
> If you look in my previous posts, I have pointed those out. We must first:
>
> 1) Be in par with Java Lucene release and keep up with commit-per-commit
> port.
>
> 2) Prove Lucene.Net is a grownup project with followers and a healthy
> community (just like Java Lucene).
>
> If we don't achieve the above, folks over at Java Lucene will not take us
> seriously, and thus we can't influence them.
>
> -- George
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
> Sent: Friday, November 12, 2010 10:36 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: dev@lucene.apache.org
> Subject: RE: Lucene project announcement
>
> 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 <st...@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
RE: Lucene project announcement
Posted by "Granroth, Neal V." <ne...@thermofisher.com>.
Is Java Lucene "grown up" ? Look at how much discussion it took to determine how to get Java out of the name :)
The discussion about advancing the algorithm in C#/.NET seems to be missing the point. If you're developing at the concept level the specific language you use becomes unimportant. However as most of the concept developers apparently find Java convenient; others wanting to participate at the concept level would find it more beneficial to join that brain-pool instead of diluting the effort by starting up elsewhere.
- Neal
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Tuesday, November 16, 2010 10:55 PM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
This topic has been coming back again and again which I have tried to
address multiple times, so let me try again.
1) Java Lucene started years before the first C# version (4+ years if I get
my history right), thus it defined and has been the definer of the
technology and the API. It is the established leader, and everyone else is
just a follower.
2) Lucene.Net is no were mature as Java Lucene, never got established
itself, or had a rich development community -- thus why we are here today.
3) If and only if, the community of Lucene.Net (or "Lucene" over at
codeplex.com) manages to proves itself to the level of Java Lucene, only
then such a community will have the voice to influence folks over at Java
Lucene. Only then you will see the two community discussing search engine
vs. port issues or the state of Lucene.Net.
If you look in my previous posts, I have pointed those out. We must first:
1) Be in par with Java Lucene release and keep up with commit-per-commit
port.
2) Prove Lucene.Net is a grownup project with followers and a healthy
community (just like Java Lucene).
If we don't achieve the above, folks over at Java Lucene will not take us
seriously, and thus we can't influence them.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, November 12, 2010 10:36 AM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
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 <st...@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
RE: Lucene project announcement
Posted by "Granroth, Neal V." <ne...@thermofisher.com>.
Is Java Lucene "grown up" ? Look at how much discussion it took to determine how to get Java out of the name :)
The discussion about advancing the algorithm in C#/.NET seems to be missing the point. If you're developing at the concept level the specific language you use becomes unimportant. However as most of the concept developers apparently find Java convenient; others wanting to participate at the concept level would find it more beneficial to join that brain-pool instead of diluting the effort by starting up elsewhere.
- Neal
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Tuesday, November 16, 2010 10:55 PM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
This topic has been coming back again and again which I have tried to
address multiple times, so let me try again.
1) Java Lucene started years before the first C# version (4+ years if I get
my history right), thus it defined and has been the definer of the
technology and the API. It is the established leader, and everyone else is
just a follower.
2) Lucene.Net is no were mature as Java Lucene, never got established
itself, or had a rich development community -- thus why we are here today.
3) If and only if, the community of Lucene.Net (or "Lucene" over at
codeplex.com) manages to proves itself to the level of Java Lucene, only
then such a community will have the voice to influence folks over at Java
Lucene. Only then you will see the two community discussing search engine
vs. port issues or the state of Lucene.Net.
If you look in my previous posts, I have pointed those out. We must first:
1) Be in par with Java Lucene release and keep up with commit-per-commit
port.
2) Prove Lucene.Net is a grownup project with followers and a healthy
community (just like Java Lucene).
If we don't achieve the above, folks over at Java Lucene will not take us
seriously, and thus we can't influence them.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, November 12, 2010 10:36 AM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
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 <st...@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.
**********************************************************************
RE: Lucene project announcement
Posted by George Aroush <ge...@aroush.net>.
This topic has been coming back again and again which I have tried to
address multiple times, so let me try again.
1) Java Lucene started years before the first C# version (4+ years if I get
my history right), thus it defined and has been the definer of the
technology and the API. It is the established leader, and everyone else is
just a follower.
2) Lucene.Net is no were mature as Java Lucene, never got established
itself, or had a rich development community -- thus why we are here today.
3) If and only if, the community of Lucene.Net (or "Lucene" over at
codeplex.com) manages to proves itself to the level of Java Lucene, only
then such a community will have the voice to influence folks over at Java
Lucene. Only then you will see the two community discussing search engine
vs. port issues or the state of Lucene.Net.
If you look in my previous posts, I have pointed those out. We must first:
1) Be in par with Java Lucene release and keep up with commit-per-commit
port.
2) Prove Lucene.Net is a grownup project with followers and a healthy
community (just like Java Lucene).
If we don't achieve the above, folks over at Java Lucene will not take us
seriously, and thus we can't influence them.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, November 12, 2010 10:36 AM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
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 <st...@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.
**********************************************************************
RE: Lucene project announcement
Posted by George Aroush <ge...@aroush.net>.
This topic has been coming back again and again which I have tried to
address multiple times, so let me try again.
1) Java Lucene started years before the first C# version (4+ years if I get
my history right), thus it defined and has been the definer of the
technology and the API. It is the established leader, and everyone else is
just a follower.
2) Lucene.Net is no were mature as Java Lucene, never got established
itself, or had a rich development community -- thus why we are here today.
3) If and only if, the community of Lucene.Net (or "Lucene" over at
codeplex.com) manages to proves itself to the level of Java Lucene, only
then such a community will have the voice to influence folks over at Java
Lucene. Only then you will see the two community discussing search engine
vs. port issues or the state of Lucene.Net.
If you look in my previous posts, I have pointed those out. We must first:
1) Be in par with Java Lucene release and keep up with commit-per-commit
port.
2) Prove Lucene.Net is a grownup project with followers and a healthy
community (just like Java Lucene).
If we don't achieve the above, folks over at Java Lucene will not take us
seriously, and thus we can't influence them.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Friday, November 12, 2010 10:36 AM
To: lucene-net-dev@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: RE: Lucene project announcement
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 <st...@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