Mailing List Archive: Directory interface

Directory interface

Jun 5, 2005, 11:48 AM

Post #1 of 3 (5066 views)

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 [ In reply to ]

chip at force-elite

Jun 5, 2005, 12:05 PM

Post #2 of 3 (4785 views)

Permalink

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

Re: Directory interface [ In reply to ]

rooneg at electricjellyfish

Jun 5, 2005, 12:12 PM

Post #3 of 3 (4802 views)

Permalink

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