Here is a somewhat adhoc list of things to fix and features to add:
#ifdef __STDC__ #define ARGS1(t,a) \ (t a) #else /* not ANSI */ #define ARGS1(t,a) (a) \ t a; #endif /* __STDC__ (ANSI) */
We would like to add a field type into the SF software which would allow for the parsing of and indexing of geographic coordinates that describe the outline of a data set or document. Software has been written outside of SF to do the parsing (using flex), and the indexing and overlay routines have been included into the freeWAIS-0.3 code. Now we need to integrate the code so that we can perform full field searching of text, dates, numbers, and geography in one indexing system.
It seems to me that if the SF crowd can consistently use the .fde file incorporated into the available .src file that a functionality like "explain" can be developed to allow the client to determine what attributes are being used and formulate a query window to match it. probably easier would be to have a "form" resource file which could be retrieved from the server (e.g. query.html) by a "smart" http client...
How about having a script that could automatically update a the database. That is, a record would be kept of which files were in the database. This record (.rec or some such) could be used instead of having to remember or find the command that created it. That is, it would support something like,
waisindex -update filename.recto rebuild the database.
Programs like this become immortal when they do not take any special knowlege to use. Format files for common data types would make FreeWAIS-sf more accessible. Maybe you've already done this but format files like, FAQ.fmt, email.fmt, usenet.fmt would be very helpful, (and probably not that hard to write.) Maybe creating an incoming directory on your ftp server would be useful, so that users could post their .fmt files and save you from having to do the work.
It seems that the functionality you have provided matches very well the basic abilities of Z39.50 V2 and V3 in terms of fields and search. If there were a way to identify registered attributes then the construction of a gateway from ZDIST to an FreeWAIS-sf store of data would be possible, allowing people to keep their data in one format and serve the V1 and non V1 communities.
My thoughts regarding a linkage between FreeWAIS-sf and a full Z39.50 V2-3 release such as ZDIST were to provide a link into the new capabilities and other "compliant" clients out there. But I think much of the API work could be done with the help of CNIDR personnel - their "linkage" back into freeWAIS-0.3 disabled some of the functionality whereas FreeWAIS-sf is more on the same level of sophistication as V2 and should be easier to connect to. If such a connection can be made it would allow you all to maintain and enhance the existing code and have some partners out here work on maintaining the API connection, taking the load off you except in consultation ...
First of all, when indexing the documents, the user should be able to specify the following for each field to be indexed:
<field> /^Authors: / au TEXT BOTH minchars 2 word /[^ ;\n=()]+/ stop abstracts_field_au.stop syn abstracts_field_syn.syn <end>Other things such as headline length should be specifiable in the .fmt file as well.