On Sunday 02 November 2003 13:49, you wrote: > > Exactly how is this a limitation? If it were the case that there WAS no > way to implement Digest authentication under the current AOLserver, I'd > say then THAT would be a limitation. > > It's important to distinguish between "not yet implemented" vs. "not > currently implementable." The former is simply not feature complete. > The latter is a flaw in the design.
Consider this: when you want to process binary data, you go to Tcl alone? Well, not really. Instead, you use C (or similar). But why? Tcl can handle binary data. There is nothing you can't do binary-wise with Tcl. It is just so clumsy and ineffective that nobody seriously uses this, apart from some very simple cases. Now, would you consider Tcl having a limitation in handling binary data? Well, *strictly* speaking not, but *practically* speaking, yes. This is the same here. Although you can do virtually anything in AOLserver by overriding all default processing using some Tcl filters, it just does not always make sense for the practical use. I would prefer some expert writes a clean plugin module for XYZ functionality and I just use it by plugging it where I need it, instead of becoming the XYZ expert myself and having to write all of that by hand over and over. This is what I call a limitation. On Apache, I'd use mod_digest, attach in on the places I need and I'm running. What about AS? If I were to use "mod_digest" like thingy, or any other alternative standard method, what should I do? > > AOLserver has few design flaws. It does, however, not very feature > complete. Given my choice, I much prefer something that does a few > things exceptionally well than something that does everything but > poorly or as a conglomeration of hacks. This is the good point: "conglomeration of hacks". This is exactly what we need to avoid by identifying what people need or might need in the future and *open* the desing so that it allows for expansion. This is for sure the case for the database layer, for example. It allows you to snap-in database engine you like. This is perhaps not the case with AS 4.0 socket processing since it's http-protocol bound. This is definitely not the case with AOLserver authentication. It is hard-wired in C for doing only Basic method, without a clean interface to implement (and integrate with the rest of the system) other XYZ methods, when (if) they come along the road. > > Is there really that much demand for Digest authentication? Other than > non-SSL WebDAV, what else actually implements Digest auth as a > requirement? > Security. The Basic authentication is acceptable for Intranet uses. Going to Internet and having passwords transmitted in a clear text form is not a very good thing, I'd say. This is what the RFC states very clearly, encouraging people to move from the basic authentication, if possible. Is this a good reason for you? Bottom line (for me): If people are happy with tossing in a custom Tcl layer atop of AS everytime they need to overcome some internal "limitations", this is ok for me. But this is bad for the AS itself. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
