> Do you already have an idea of the name to use ?
> Search::Htdig ? Htdig
> (AltaVista has a top level name after all). I vote for Htdig.
> Lower level
> interfaces could have Htdig::Word, Htdig::Documents etc.. names.
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 not yet a CPAN contributor, by the way. I'll get onto that.
> Right. This leaves us with the need to define a syntax tree.
> I tend to
> like the Text::Query syntax tree (for obvious reasons :-) but
> you may think
> differently.
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
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.
> XML/RDF would be the format of choice to represent the database
> contents. A DBI based perl CGI that would translate any SQL database
> into a single XML/RDF format could be the solution. Two drawbacks :
> very inefficient (impractical for databases that contain more
> than 100 000
> records) and does not solve the fact that the inverted index
> is not suited. The other approach is to take mysql++, get rid of
> templates, add an interface for at least another database (postgres),
> change the interface to be as close as possible to DBI interface,
> rename it sql++ (or dbi++ ;-), plug it in htdig. Add a word.desc in
> htcommon suited to databases so that WordKey is able to handle it,
> generalize the htdig code so that it does not depend on a specific
> word key layout.
I have to admit I've no idea what you're talking about here. I've probably
got some homework to do before I'm online with these concepts. Suffice it
to say, you're much deeper into the internals of this than I am, and
probably have much more specific and informed desires. I myself just want
to be able to perform a search through a native Perl interface without
disturbing the htdig architecture too much, and provide programmers of other
languages (java, python, c++, etc.) with the capability to do the same
thing.
More after lunch...
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.
