lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 小康 <xiaok...@cnblogs.com>
Subject Re: State / Future of the Lucene.Net Project
Date Thu, 21 Jun 2018 08:41:09 GMT
Hi,
I think I need to do some preparation.
I will try do this job in my free time and I have confidence to do it.
Will I contact with you in this way in the future?



2018-06-21 16:15 GMT+08:00 Stefan Bodewig <bodewig@apache.org>:

> On 2018-06-21, Shad Storhaug wrote:
>
> > There are still many undecided issues regarding the ICU functionality.
> For example:
>
> > 1. Should we use the newly ported ICU4N (https://github.com/
> NightOwl888/ICU4N) project or try to add the functionality to the already
> existing icu.net project (https://github.com/sillsdev/icu-dotnet)? Note
> the latter has been attempted, but there are several issues (missing
> functionality, incompatibilities, problems loading data) that make it very
> challenging to provide all of the Lucene.Net.ICU functionality - it was
> easier to get it working by porting from ICU4J, but will require
> maintaining the ICU4N project.
> > 2. If we use ICU4N, should we make it into a general library that
> benefits all of the .NET ecosystem, or should we limit it to primarily
> support Lucene.NET?
>
> I'm not doing any of the work, so take this with a big grain of salt.
>
> Right now I'd focus on what is best for Lucene.Net and try to safe the
> (.NET) world later. To me it looks as if going with ICU4N in its current
> state is the best short term option. If you want to turn ICU4N into
> something useful then this sounds (1) very useful and (2) like a lot of
> work. Most likely the people who'd want to contribute to ICU4N and
> Lucene.Net are not the same (apart from yourself), so I'd separate
> growing ICU4N from which version of ICU4N Lucene.Net should use. We can
> probably switch to a more full-blown version of ICU4N if/when such a
> beast eists. Most probably I'm missing something.
>
> > Basically, there are 3 ways to complete this:
>
> > 1. Add the required functionality to the icu.net project in order to
> support the Lucene.Net.ICU features, port the missing Lucene.Net.ICU
> features to the current master branch and abandon work on ICU4N.
> > 2. Finish up the API and fix 19 failing tests to make ICU4N good enough
> to support Lucene.Net.ICU without making it into a first-rate component
> that supports all ICU features.
> > 3. Contact the ICU team about contributing ICU4N to their repository and
> if they agree, allow them to lead the direction of the API and features
> (with the added possibility of their help and Unicode expertise).
>
> I'd opt for 2 - and 3 after 2 is done. But see the disclaimer above.
>
> Stefan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message