> I think for most people the issue is more access to the DB so we can
> modify or do our own hooks into it. And for really large sites,
> scalibility- being able to do searches and digs at the same time.
I think people wanting to access the database on their own is indication
that htdig has too many limitations. More effort should be put into making
htdig itself accomodate the needs of insertion, deletion, and updating,
which would make access to the database unnecessary. Excalibur's model
would be a place to start (although it could certainly use improvement).
> One feature I'd like to see is a object for PHP and/or Perl so that
> database driven sites can not only update their site, but the search
> engine in real-time. Basically, never having to do another dig again.
With the concept of a "dig" being a full scan of an indexed site, I can
understand why someone would want to avoid it. But this again points up the
limitations in the htdig interface, not allowing incremental updates, etc.
I think if htdig were expanded to allow someone else to determine what data
should be added, but to actually allow them to do it through htdig's custom
interface, rather than directly to the database, this would make htdig a
much better product. Then the developer could forget what was behind htdig
altogether and simply concentrate on updating the information. I'd rather
not know what database htdig was using.
> And for that matter a PHP/mod_perl ready object for searches as well.
> That way we can take advatage of persistent SQL sessions.
> Doing SQL hits
> via a CGI will have a significant performance hit if you have
> to reconnect
> to the DB each time, and it also saves a fork().
This is a good point. I'm not sure how an expanded htdig interface would
allow this particular option, either, since cross-language database
connections would get tricky. Maybe a persistable connection to
htdig/htsearch would work instead, and that connection would have a database
connection associated with it. That's probably getting a bit far out,
though.
I am working on a perl-htsearch interface and hope to have it completed in
early January. This will allow direct access to the resultlist from
htsearch, but won't persist the database connections. You'll use it like
so:
use HtDig::Searcher;
my $srch = new HtDig::Searcher();
my $result = $srch->execute("words to search for");
Or something similar to that...
Another question: Has anyone ever considered a daemon-based implementation
of htdig/htsearch, as opposed to the command line interface? I vaguely
remember seeing this brought up in a thread, but possibly not here.
Jamie
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
