Geoff Hutchison writes:
> [EMAIL PROTECTED] wrote:
> > 1) Switch to automake + libtool
>
> I'm not so sure about using automake, though libtool has been on my list
> for a while. It would be nice to have htlib and htcommon be shared since
> users may have multiple copies of htdig or htsearch running at the same
> time.
The motivation to use automake is that it makes it a lot easier to
deal with libtool. Unless you have very bizarre Makefiles, using automake
is quite straight forward.
> My only complaint about automake is that the generated Makefiles seem so
> massive compared to hand-coded ones. It seems like killing a gnat with a
> bazooka.
Yes but they do a lot of nice things and you don't have to do it
by hand. And, again, I'd say it's a must if you don't want to an
endless fight with libtool :-)
> At the moment, I was thinking along the lines of an ODBC subclass of
> Database, but I think people would be quite happy to see some sort of
> SQL support, regardless of implementation.
Right. I don't like ODBC because despite the fact it's a so-called
standard it's done the wrong way. It should be a standard protocol
between the application and the database server. Instead it's a
standard protocol between the application and a driver on the local
machine and the driver must talk native language with the remote
database. Silly way to do things, IMHO.
From my experience it's *very* hard to remove dependency on a specific
SQL database if you don't do it in the first place. I did that mistake
with my crawler and Catalog (depend on MySQL) and have a hard time
to isolate the database specifics (table schemas, specific SQL idioms,
return values, autoincrement fields etc.).
> URLs to update based on access time and/or other parameters. This
> requires the database updates to keep the data in a consistent state,
> which isn't true in 3.1.x--you need to stop the indexer to run htmerge.
Ok, we argree on this : a database is needed.
> There are also issues with performance scalability. But you asked
> initially whether it could handle millions of URLs. It *can*, but that
> doesn't mean it can't be improved. ;-)
:-)
> I don't know whether you're mentioning that we *do* actually have a real
> database (unlike some programs), or whether you question the Berkeley
> DB's ability to handle as "a real database."
Basically it was the fact that Berkeley DB does not behave like a real
database.
> I doubt you'll get any disagreement on this list. But for the record
> I'll state that at the present time *I'm* not interested in job offers.
> Even if I was, I wouldn't want to discuss it on a public list. ;-)
Right, neither would I. Let's go back to work then. I'm starting the
automake + libtool stuff and ring the bell when it's ready. I'll make
it all static (as it is now) to make sure I didn't break anything.
Cheers,
--
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.
