Tillman, James writes:
>
> I agree that a top level HtDig space is best for these utility-type
> functions. I see no reason to use the Search:: namespace since many of the
> modules that will be written may have nothing to do with searching.
> Secretly, what I'm really wanting for my own development needs is
> DBI::htDig, but that will take some time I'm sure.
>
I'm curious, why would you want a DBI::htDig (You probably mean DBD::htDdig) ?
DBI is designed for SQL databases. htdig interface is not and will never (?)
be SQL. Beside, there is a number of issues that htdig will need to address
and that won't fit in the DBI<->DBD relationship. Am I missing something ?
Maybe what you'd like is a kind of extension to DBI that would transparently
index database content ? I'm afraid you'll have a very hard time with that :-)
>
> No preference on that, although I think I didn't make myself clear enough on
> where I was at. What I'm currently doing is working on getting htDig's own
> parser into a class that is set apart from the htsearch CGI program. Right
> now, it's part and parcel of the whole thing. Once I get the parser classed
I understand from what you say that:
. You rewrite part of the htsearch classes so that they do not depend on
cgi parameters to work.
. You have not (yet) tried to split the query parsing/resolution into two
separate set of functions.
> out, modifications to it would probably be best done in the C++ class
> itself, since other systems not written in perl would want to be able to
> perform queries, too. Preferably PERL woudn't have to do any syntax trees
> itself, but would simply use the C++ interface. I'm not really into
> reinventing the wheel, just making the current ones roll better.
I get your point.
I strongly think that a Perl interface to htdig should take advantage
of the Text::Query modules. Not doing so closes doors and duplicate
efforts. We could do a *very* simple htdig driver in Text::Query that
only works with htdig syntax. And it could be used in the Htdig::
module. This will not require more work on your part to do it this way
than to hard code it. But it will have the *great* advantage of opening
the path to support various query syntax for htdig (AltaVista for a start).
You will not be required to do it but people who want it will have the
framework to implement it.
If the first thing you want is a working perl interface, I think
that you don't even need to split the query parser/solver into two
classes. It will work the way it is.
--
Loic Dachary
ECILA
100 av. du Gal Leclerc
93500 Pantin - France
Tel: 33 1 56 96 09 80, Fax: 33 1 56 96 09 61
e-mail: [EMAIL PROTECTED] URL: http://www.senga.org/
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
