On Wed, Mar 10, 2004 at 09:10:06AM -0800, Jamie Herre wrote:
> 
> const char **SwishPropertyNames( SW_HANDLE );

The properties and metanames are related to a specific index, so the 
handle won't work alone -- need to also specify the index file name.


For some reason there's a single table in the header of each index that 
lists both properties and metanames.  IIRC, I did create a mapping table 
to just hold the properties, but not one for metanames.  (I wanted to 
references properties sequentially.)

So, what's needed is two (already have one, I think) null terminated
tables that are a list of pointers to props/metas.  That would give a 
way to generate a list of objects in Perl or other higher language.

   void **prop_list = SwishFetchPropList( sw_handle, "index_file" );
   const char *name SwishProperty_name( prop_list[0] );
   int id SwishProperty_id( prop_list[0] );

So in Perl you could do:

    my @props = $handle->FetchPropList( "index_file" );
    for my $prop ( @props ) {
       print "Property name = ", $prop->name, 
             "id number = ", $prop->id,"\n";
    }

or something like that, anyway.  


> I'm also guessing that SwishPropteryNames() should return all property 
> names in the index and we'd follow the convention that those beginning 
> with "swish" are standard and those which do not were set via 
> PropertyNames directives.

You can say: MetaNames swishtitle swishdocpath so the distinctions are 
not clear -- the swish* ones are just pre-defined.  I wouldn't put any 
logic into the API for excluding swish* names.

> Anyway, I'd like to do it in a way that I could contribute back so let 
> me know if I'm on the right track or not.

If you are up for code hacking that's great.  Look at metanames.c for 
ideas.  Need to make sure that there's the mapping tables for each 
property in the index's header and provide methods to access them.

So does that API make sense?  I may be forgetting something obvious.  
Like I said, I worked on this once before for a day and there was 
something that got in the way of implementing it.  I just can't 
remember what that was.



-- 
Bill Moseley
moseley@hank.org