Re: CFS file and file formats

[Doug Cutting <cu...@apache.org>]

Bernhard Messer wrote:
>> I understand the technical reason for main() there, but logically this
>> belongs to an external utility class, I think.
>>
> Otis you are right, i already thought about it. It could be simply moved 
> to a newly created class in org.apache.lucene.util package. But then we 
> have to change the visibility of CompoundFileReader to public. I have no 
> problems with a public CompoundFileReader class. Does anybody see a 
> reason that the visibility of CompoundFileReader should not be changed 
> to public ?

Yes.  Historically we've tried hard in Lucene to not make things public 
unless they're useful to users.  We try to keep the public API as small 
as possible.  This makes the documentation easier to read and also makes 
the system easier to maintain.  CompoundFileReader is an implementation 
class, not a user class.

Doug

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

Re: CFS file and file formats

[Bernhard Messer <bm...@apache.org>]

Doug Cutting schrieb:

> Bernhard Messer wrote:
>
>> Why not implementing a small utility class, f.e CompoundFileUtil.java 
>> within the org.apache.lucene.index Package ? This class could be 
>> public and implement the necessary functionality. This is what i 
>> would prefer, because we don't have to change the visibility of 
>> CompoundFileReader or other parts of the API. The other option would 
>> be to add a public static method to IndexReader class. But i don't 
>> like to overwhelm IndexReader with a method, just a very small 
>> audience would use.
>
>
> Currently IndexWriter is the only public place in the API where the 
> compound format appears.  So, until we decide to expose index formats 
> more systematically, I think this should stay at the IndexReader level.
>
> Thus I would prefer a main() on IndexReader that had various commands, 
> perhaps something like:
>
>   java org.apache.lucene.index.IndexReader <dir> cfs list
>   java org.apache.lucene.index.IndexReader <dir> cfs extract
>   java org.apache.lucene.index.IndexReader <dir> unlock
>   java org.apache.lucene.index.IndexReader <dir> list-segments
>
this looks ok for me for the moment, but i still favorite an additional 
class within the same package. Something like "IndexUtil" which could 
hold all this kind of functionality. If there is some time over the 
weekend, i will have a look on it how much effort it will be to have 
those 4 methods in IndexReader.

Bernhard

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

Re: CFS file and file formats

[Doug Cutting <cu...@apache.org>]

Bernhard Messer wrote:
> Why not implementing a small utility class, f.e CompoundFileUtil.java 
> within the org.apache.lucene.index Package ? This class could be public 
> and implement the necessary functionality. This is what i would prefer, 
> because we don't have to change the visibility of CompoundFileReader or 
> other parts of the API. The other option would be to add a public static 
> method to IndexReader class. But i don't like to overwhelm IndexReader 
> with a method, just a very small audience would use.

Currently IndexWriter is the only public place in the API where the 
compound format appears.  So, until we decide to expose index formats 
more systematically, I think this should stay at the IndexReader level.

Thus I would prefer a main() on IndexReader that had various commands, 
perhaps something like:

   java org.apache.lucene.index.IndexReader <dir> cfs list
   java org.apache.lucene.index.IndexReader <dir> cfs extract
   java org.apache.lucene.index.IndexReader <dir> unlock
   java org.apache.lucene.index.IndexReader <dir> list-segments

etc.

Doug


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

Re: CFS file and file formats

[Bernhard Messer <bm...@apache.org>]

Doug Cutting schrieb:

> Bernhard Messer wrote:
>
>>> I understand the technical reason for main() there, but logically this
>>> belongs to an external utility class, I think.
>>>
>> Otis you are right, i already thought about it. It could be simply 
>> moved to a newly created class in org.apache.lucene.util package. But 
>> then we have to change the visibility of CompoundFileReader to 
>> public. I have no problems with a public CompoundFileReader class. 
>> Does anybody see a reason that the visibility of CompoundFileReader 
>> should not be changed to public ?
>
>
> Yes.  Historically we've tried hard in Lucene to not make things 
> public unless they're useful to users.  We try to keep the public API 
> as small as possible.  This makes the documentation easier to read and 
> also makes the system easier to maintain.  CompoundFileReader is an 
> implementation class, not a user class.
>
Why not implementing a small utility class, f.e CompoundFileUtil.java 
within the org.apache.lucene.index Package ? This class could be public 
and implement the necessary functionality. This is what i would prefer, 
because we don't have to change the visibility of CompoundFileReader or 
other parts of the API. The other option would be to add a public static 
method to IndexReader class. But i don't like to overwhelm IndexReader 
with a method, just a very small audience would use.

Bernhard

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


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