On Wed, 5 Feb 2003, Alex Lyons wrote:

> >That info is not stored in a config file, rather in the index.  
> Since
> >the list of properties and metanames is static for an index I didn't
> see
> >any advantage of a library interface over piping swish-e -T
> >index_metanames since you only need to do that once in a persistent
> >environment.  If not running persistent then use Storable to cache
> the
> >names.
> 
> The advantage is that you don't have to fork a swish-e process, even
> once, so you dont need to include all that fork and windows_fork code,
> or code to parse the results from the swish-e executable.  Isn't that
> what the API is supposed to be all about?  IMHO it ought to be
> fundamental that an API can retrieve all the information stored in the
> index.

The real advantage of the swish library is speed in a persistent
environment.  I agree that the API should give as much info as you might
want.  The property names are stored in the index so that when you ask for
a property by name it knows how to look it up in the index.  I didn't
think about it the other way around.  Typically, I always know what
metaneams are in an index in the first place since I created the index.

It would not be a hard feature to add, though.  I'll take a look.

In the mean time, you can do what I do and grab the property names with
something like this the first time you need them:

  my @props = map { /\s*([^\s]+)/; $1 } 
      grep { / META_PROP:/ }  `swish-e -T index_metanames`;


> A good example of where an API to retrieve this info would be needed if
> the script doesn't know in advance what properties/metanames are present
> and what kind they are.

Sure, in some cases.  Wouldn't work for swish.cgi that's bundled with
swish-e, though.  You have to know something about the property to display
it.  If you have a property named "bla" there's really no way to know how
to display it and what description it should have.


-- 
Bill Moseley moseley@hank.org