Directory interface

[Garrett Rooney <ro...@electricjellyfish.net>]

The current interface exposed by Lucene4c requires the user to pass in a 
path when a directory is needed, as opposed to using an actual directory 
object.

Advantage: Less code to write, no need to create yet another object when 
you want to access a local directory.

Disavantage: No way to use something other than what amounts to an 
FSDirectory under the hood.  Now most of the time what you want is an 
FSDirectory, but there's nothing that requires that to be the case, and 
other directory implementations do exist in the Java code that we could 
wrap, not to mention the fact that we could provide our own interface 
for implementing one in C.

Since C doesn't let you have multiple versions of a function with the 
same name and different arguments, if we want to allow the user to use 
both paths and directory objects that means two versions of every 
function that takes a directory, with slightly different names, which I 
don't particularly like.

I'm leaning towards going in and creating a directory object again (this 
is what the pre-GCJ version of Lucene4c did, and it seemed reasonable), 
and requiring people to create one before doing anything that requires a 
directory.  This way we retain the ability to add more directory types 
in the future without screwing with the interface and without adding a 
ton of extra functions.

Thoughts?

-garrett

Re: Directory interface

[Garrett Rooney <ro...@electricjellyfish.net>]

Paul Querna wrote:

> why can't we have a simple struct that wraps the FSDirectory?
> 
> All it needs is an int to identify each Directory object type, and 
> either a void* or Union that we can cast.  Yes, its not super pretty, 
> but it means one API..... I would suggest not even making this structure 
> public.

It doesn't even need to be that complex really.  Something like:

struct lcn_directory_t {
   org::apache::lucene::store::Directory *impl;
};

And then if we want to implement a C level version we just have a C++ 
class that inherits from Directory and uses a bunch of callback 
functions and a void pointer to allow you to do the actual 
implementation in C.

The question isn't really about how to implement the directory object, 
the question is if we feel that it's worthwhile to require a directory 
object be created before you do anything that requires a directory.

It's the difference between:

lcn_index_searcher_t *searcher;

lcn_index_searcher_open (&searcher, "path/to/index", pool);

and

lcn_index_searcher_t *searcher;
lcn_directory_t *dir;

lcn_fs_directory_open (&dir, "path/to/index", pool);

lcn_index_searcher_open (&searcher, dir, pool);

-garrett

Re: Directory interface

[Paul Querna <ch...@force-elite.com>]

Garrett Rooney wrote:

> The current interface exposed by Lucene4c requires the user to pass in 
> a path when a directory is needed, as opposed to using an actual 
> directory object.
>
> Advantage: Less code to write, no need to create yet another object 
> when you want to access a local directory.
>
> Disavantage: No way to use something other than what amounts to an 
> FSDirectory under the hood.  Now most of the time what you want is an 
> FSDirectory, but there's nothing that requires that to be the case, 
> and other directory implementations do exist in the Java code that we 
> could wrap, not to mention the fact that we could provide our own 
> interface for implementing one in C.

why can't we have a simple struct that wraps the FSDirectory?

All it needs is an int to identify each Directory object type, and 
either a void* or Union that we can cast.  Yes, its not super pretty, 
but it means one API..... I would suggest not even making this structure 
public.

-Paul