At 8:06 PM -0500 11/24/99, Tom Metro wrote:
>Does this work? (I haven't tried it.) If so, why isn't this mentioned
>in some intro document or why doesn't configure prompt the user to set
Yes, it works very well. I've been hoping that we could get several
example config files together to demonstrate some of the uses. This
was one thought with a discussion about reorganizing the
documentation as well. Often it makes more sense to consider
attributes in combination, but this doesn't fit with our current
documentation format.
>I'd suggest that this should be a string list the same as
>remove_default_doc is. The same rationale applies.
Sure. Everyone agrees on this point. But right now the main
contributors have their plates full. So unless someone actually
contributes the changes, it won't happen soon. I'd be glad to point
out the code in question.
>Ideally, one would like to see configure ask for the path to an Apache
>config file and it would extract information like this. (Though
>understandably not trivial to do.)
While I use and like Apache a great deal, I'm not sure this is a
great idea. If you do it for Apache then people start asking why you
don't do it for Netscape, Roxen, IIS, etc. Plus, many people use
binary pacakges, which will likely use these defalts anyway.
>That may make sense. It is also possible that you might just want to
>concede that Ht://Dig isn't going to be optimized for speed. Instead
Eh? I don't think many people would consider ht://Dig particularly
easy to administer. It would certainly help to have a more
user-friendly admin interface. Besides, if you're looking for ease of
installation or administration, you're probably going to use some of
the various websites out there that will do it for you.
Flexible? You bet?
Capable? We have reports of users satisfied with performance on 500,000+ URLs.
Scalable? Needs work.
When I came on as maintainer people complained it was buggy and
dumped core often. I still make the same statement: Show me a genuine
coredump and I'll send you a patch.
Speed is a lot more difficult to fix, esp. w/o accurate profiling
measurments. But the moment a consensus comes that tells me "we
should give up on speed," I'll leave. Personally, I consider getting
a stable, feature-rich, flexible system out the door as my prime
goal. But I also stated in both the 3.1.0 and 3.2.0b1 feature freezes
that I consider speed improvements as "bug fixes." :-)
>By the way, when did you switch from GDBM to Berkeley DB2? I tried
3.1.0b1.
>If I can get things to work, I'll update those Perl scripts to
>Berkeley DB2 and submit them to you guys. They appear to be pretty
They'll need more updating than that. As I mentioned on a few
threads, they need some XS magic to hook into the database. James
Tillman is working on something similar, focusing more on the search
end of things. But beyond using Berkeley DB2, the code now
encodes/compresses URLs as well as excerpts.
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You'll receive a message confirming the unsubscription.
