Bill, others,

>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.

A property might be a date, or a value, or a long description -- so
I'd expect that the application would need to know not just what props
are
in an index, but what they mean, so they can be displayed in a
reasonable
way, perhaps with better human-readable names.  In the swish.cgi
script
you list both the property names, and a hash to map those to a better
description of that property (e.g. mdate => 'Last Modified Date' ).

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.

Alex.

-------------------------------------------------------------------
  This e-mail and any attachments may contain confidential and/or
  privileged material; it is for the intended addressee(s) only.
  If you are not a named addressee, you must not use, retain or
  disclose such information.
  Serco cannot guarantee that the e-mail or any attachments are
  free from viruses.
  Serco Group plc. Registered in England and Wales. No: 2048608
  Registered Office: Dolphin House, Windmill Road,
  Sunbury-on-Thames TW16 7HT, United Kingdom.
-------------------------------------------------------------------