lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eyal Post" <eyalp...@epocalipse.com>
Subject RE: Compression Implementation
Date Tue, 16 May 2006 17:11:11 GMT
I want to keep this change as simple and small as possible. Lucene.Net
already reads some configuration settings from the app.config file (see the
SupportClass.AppSettings) so I'll just use that. 

Eyal

> -----Original Message-----
> From: Jeff Rodenburg [mailto:jeff.rodenburg@gmail.com] 
> Sent: Tuesday, May 16, 2006 0:16 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Compression Implementation
> 
> I like Eyal's suggestion in keeping the adapter definition to 
> implementing an interface.
> This would be initiated through a reflection call, yes?
> 
> I would add that the configuration information could be 
> driven via custom config sections, which I've done a 
> bazillion of lately.  If it would help, I'll do the code for 
> custom configuration sections that ensure the requisite data 
> is loaded from the config file in a structured manner.
> 
> -- j
> 
> On 5/15/06, Eyal Post <eyalpost@epocalipse.com> wrote:
> >
> > What I was thinking of doing is this:
> > Declare an interface for compression:
> >
> >   public interface CompressionAdapter
> >   {
> >     byte[] Compress(byte[] input);
> >     byte[] Uncompress(byte[] input);
> >   }
> >
> > Allow users to develop an adapter that implements this 
> interface (i.e.
> > SharpZLibCompressionAdapter).
> > The user then add the adapter class name to the app.config file and 
> > Lucene will dynamically create an instance of that adapter.
> >
> > This means there's no actual dependency from Lucene to any 
> 3rd party 
> > library. If the adapter is not configured, compression will 
> not work, 
> > if it is - this it's the user responsibility to provide the 
> > compression library and an adapter.
> >
> > Eyal
> >
> > > -----Original Message-----
> > > From: George Aroush [mailto:george@aroush.net]
> > > Sent: Monday, May 15, 2006 23:48 PM
> > > To: lucene-net-dev@incubator.apache.org
> > > Subject: RE: Compression Implementation
> > >
> > > Hi Eyal,
> > >
> > > First thanks for taking on this task, it's much appreciated.
> > >
> > > The reason why I believe we need a reflection base solution is 
> > > because the current code of Lucene.Net must remain independent of 
> > > 3rd party requirement.
> > > For example, if you look at the Test code for Lucene.Net, 
> you can't 
> > > compile or run it without having NUnit be installed on 
> your machine 
> > > and have the code reference the library.  If your 
> solution will have 
> > > similar requirement, then I don't think we can accept it for 1.9.
> > >
> > > Reflection seems to me is the only way to save this problem.
> > >
> > > After putting together the reflection code in Lucene.Net's code 
> > > base, we still have to provide an interface which a user 
> much code 
> > > to in order for the compression code to be in a working order and 
> > > utilized by Lucene.Net.
> > > But this code, because it's not a physical part of Lucene.Net, it 
> > > doesn't put any restriction on Lucene.Net to require a 3rd party 
> > > library/code to be present to use Lucene.Net -- unless if 
> the user 
> > > wants compression.
> > >
> > > Again, thanks for taking on this task.
> > >
> > > Regards,
> > >
> > > -- George Aroush
> > >
> > > -----Original Message-----
> > > From: Eyal Post [mailto:eyalpost@epocalipse.com]
> > > Sent: Monday, May 15, 2006 4:24 PM
> > > To: lucene-net-dev@incubator.apache.org
> > > Subject: RE: Compression Implementation
> > >
> > > I'm on it.
> > > Just wondering, why take the reflection way and not the 
> interface way?
> > > Interface way seems more "correct" and will also perform better.
> > >
> > > Eyal
> > >
> > >
> > > > -----Original Message-----
> > > > From: George Aroush [mailto:george@aroush.net]
> > > > Sent: Monday, May 15, 2006 21:54 PM
> > > > To: lucene-net-dev@incubator.apache.org
> > > > Subject: RE: Compression Implementation
> > > >
> > > > Hi Jeff,
> > > >
> > > > We need compression support in Lucene.Net 1.9 using .NET
> > > 1.1 otherwise
> > > > 1.9 can't be declared compatible with it's Java based
> > > index.  Beside,
> > > > doing reflection to provide a plug-in solution to a 3rd party 
> > > > compression isn't hard.
> > > >
> > > > Eyal already asked if he can work on this part.  I said yes
> > > but I have
> > > > not heard back from him yet.
> > > >
> > > > Eyal: If you are reading this, please let us know if you
> > > are taking on
> > > > this task or not.  Thanks!
> > > >
> > > > Regards,
> > > >
> > > > -- George Aroush
> > > >
> > > > -----Original Message-----
> > > > From: Jeff Rodenburg [mailto:jeff.rodenburg@gmail.com]
> > > > Sent: Monday, May 15, 2006 12:32 PM
> > > > To: lucene-net-dev@incubator.apache.org
> > > > Subject: Re: Compression Implementation
> > > >
> > > > Looking at this from a bit broader perspective, this opens
> > > up a bigger
> > > > conversation.
> > > >
> > > > While working to implement a third-party hook-by-reflection 
> > > > process into the code, the .NET 2.0 framework already 
> contains the
> > > appropriate
> > > > classes to handle compression.
> > > > While there's a need for .NET 1.1 compliance, doing so with a 
> > > > round-about method seems more like an exception approach vs.
> > > > a standard approach.
> > > >
> > > > I don't mean to suggest that usage for the 1.1 Framework be
> > > abandoned;
> > > > I'm sure there is greater 1.1 usage out in the world as 
> opposed to 
> > > > 2.0.
> > > > However, jumping through hoops to support 1.1 is also just
> > > a stopgap.
> > > > I know there is a plan to move to the 2.0 Framework later
> > > on when the
> > > > java-based Lucene project hits its 2.0 definition.
> > > >
> > > > Would it be worthwhile to consider a side-by-side port to the 
> > > > 2.0Framework?
> > > > I ported
> > > > 1.4.3 to the 2.0 Framework myself last winter, and it 
> has changed 
> > > > a few underlying things as well as improved several 
> core classes.
> > > > Having used the 2.0 Framework for the past 6 months, I
> > > would strongly
> > > > suggest we consider this as a possible solution.
> > > >
> > > > Thoughts?
> > > >
> > > > -- j
> > > >
> > > > On 5/11/06, George Aroush <george@aroush.net> wrote:
> > > > >
> > > > > Hi Johnny,
> > > > >
> > > > > I have to keep Lucene.Net 1.9 .NET 1.1 compliant.  Since .NET 
> > > > > 1.1 doesn't have compression API, I couldn't implement this
> > > > port -- thus,
> > > > > I left it out.
> > > > >
> > > > > My idea on how to resolve this is to use reflection 
> and through 
> > > > > reflection, one can integrate a 3rd party compression into
> > > > Lucene.Net
> > > > > 1.9.  If you want to take on this part, please do and submit 
> > > > > your code.  Your effort will be more then welcome and 
> is a path
> > > > to becoming
> > > > > a committer for Lucene.Net.
> > > > >
> > > > > Regards,
> > > > >
> > > > > -- George Aroush
> > > > >
> > > > > -----Original Message-----
> > > > > From: J C [mailto:roamingcode@hotmail.com]
> > > > > Sent: Wednesday, May 10, 2006 7:51 PM
> > > > > To: lucene-net-dev@incubator.apache.org
> > > > > Subject: Compression Implementation
> > > > > Importance: High
> > > > >
> > > > > Hello George
> > > > >
> > > > > I have found this:
> > > > > // {{Aroush-1.9}} for .NET 1.1, we can use reflection 
> and ZLib?
> > > > > in FieldsWriter.cs. It seems that the ZIP compression 
> is not yet 
> > > > > implemented.
> > > > >
> > > > > I would like to give it a try. Please confirm.
> > > > >
> > > > > Regards
> > > > > Johnny
> > > > >
> > > > > 
> ________________________________________________________________
> > > > > _ Be the one of the first to try the NEW Windows Live Mail.
> > > > >
> > > > >
> > > >
> > > 
> http://ideas.live.com/programPage.aspx?versionId=5d21c51a-b161-4314-
> > > 9b
> > > > > 0e-491
> > > > > 1fb2b2e6d
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> 


Mime
View raw message