FAQ
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

Search Discussions

  • Paul Querna at Jun 5, 2005 at 7:07 pm

    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
  • Garrett Rooney at Jun 5, 2005 at 7:13 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupc-dev @
categorieslucene
postedJun 5, '05 at 6:48p
activeJun 5, '05 at 7:13p
posts3
users2
websitelucene.apache.org

2 users in discussion

Garrett Rooney: 2 posts Paul Querna: 1 post

People

Translate

site design / logo © 2021 Grokbase