> 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 :-)
Nope. Although you were correct about it being DBD::htDig instead of
DBI::htDig. I was dreaming of the day I'd be able to do this:
use DBI;
$dbh = DBI->connect("DBI:htDig");
$sth = $dbh->prepare("select * from site1_catalog");
$sth->execute();
..
I see no insurmountable problems in a query-only htDig DBD. For example,
one thing that makes Microsoft's Index Server so easy to use is the familiar
interface. If you know ADO, you can use Index Server and get back
recordsets in response to your queries using a modified SQL syntax. I want
a perl programmer who knows DBI to be able to query htDig through a DBD.
All it takes is the ability to parse the sql statement into a valid htDig
query. DBD's have been written for text files, so DBI is obviously not
restricted to SQL Databases.
I read recently that the DBI distrib is second only to CGI as the most
popular CPAN download. As I've told Geof, when PERL is able to query htDig
through DBI using simple SQL syntax, I think its popularity will skyrocket,
and if htDig is ready for it, SQL query interfaces other languages will
quickly follow.
> 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).
I can see what you mean about using Text::Query to parse queries from the
PERL side and I see no reason not to do it, but keep in mind that whatever
is implemented in PERL won't be enjoyed by the users of any other
programming language. It would be many times more effective to duplicate
PERL's Text::Query capabilities in htDig itself and let everyone take
advantage of this flexibility.
> 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.
I agree, and I'm almost done getting the parser/searcher separated from the
CGI. But at some point, I want the perl user to be able to "prepare" his
statement prior to executing it, which means providing a parser interface as
well as a searcher.
Jamie
------------------------------------
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.
