Of course they are kludges, AOLServer and 4.x versions in particular, designed to be HTTP only. Current AOLServer driver model considers HTTP protocol only and is being optimized to support HTTP or HTTP-like protocols only. I doubt AOL will ever change the whole driver model again to un-HTTP it, i.e. making driver architecture multi-protocol but less HTTP-efficient. That's why, at least my patch, does not change HTTP driver at all, it just makes a little short-cut to stop HTTP processing and passing socket to other protocol handler. It will work with future versions, it works with 4.1 as well. It is similar to existing TCl callback approach, but uses connection pooling, without pre-filters, they are HTTP specific.
As for breaking if driver changes, haven't it happened with versions 3.1, 3.5, 4.0, 4.1. With every version we have bunch of things not working, openssl comes to mind, modules and drivers API changed. So this argument do not hold water.
Dossy Shiobara wrote:
On 2004.08.17, Andrew Piskorski <[EMAIL PROTECTED]> wrote:
Therefore, fairly arguing that, "No, we should NOT apply EITHER of these two multi-protocol patches, BECAUSE..." requires that the "BECAUSE" part suggest real, actual NEGATIVES to these patches, and at least the possibility that these negatives may outway the positives.
No, we should NOT apply EITHER of these two multi-protocol patches,
BECAUSE ... the entire driver model is being reworked for 4.1. Can the same functionality be implemented against 4.1 without getting in the way of the rest of the code?
BECAUSE ... while both patches make AOLserver do what the original authors intended, I personally don't think the solution is right. It may work, but they're both kludges. I personally don't believe that AOLserver's connection processing model (in either 4.0 or 4.1) is good for a long-lived TCP connection, but rather geared toward short-lived TCP connections with one request and one response, such as with HTTP.
In short, it makes no sense to argue that, "There is no value to these patches." We already knows that they DO have value.
I agree, there is value in the ability to implement high-performance non-HTTP servers within AOLserver. My personal feelings are that neither of the two proposed patches do it right. They both piggy-back on the existing HTTP driver, which is bad because it makes the functionality fragile: significant changes or optimizations in the HTTP driver could totally break non-HTTP servers, leaving anyone relying on those features out of an upgrade path.
I don't want to recommend people build non-HTTP servers on AOLserver if they won't be properly supported and feature-complete in future versions. I'd rather say "it's unsupported for NOW" than to say "you're supported, but the feature might vaporize in the future if it's inconvenient to support."
We already have people who refuse to upgrade from AS 2.x and 3.x and I'm working hard to correct that. I'm pushing hard to get features back into 4.1 to enable folks to upgrade to it from older AOLserver versions.
I don't want to see a patch go in now that, in 6 months to a year, cause people to say "I can't upgrade to the latest release because you broke non-HTTP server capability and I rely on it in a production environment, and ..., and ..., and ..." -- can you sympathize with me?
What, if any, is the risk of applying these patches? Since they are each in production use on at least one site, and have aleady been independently reviewed by Zoran, my initial assumption is that the risk is pretty low. So far I've seen nothing to suggest otherwise.
I hope I've given at least one rational reason why I think applying these patches, in their current form, isn't a great idea. I might be alone here, but that's okay.
To summarize: I think the feature being requested is useful and important, but I don't think either of the two patches submitted implement the functionality in such a way that we won't regret it in a future release.
I'm glad that people have taken it upon themselves to implement this functionality for their own projects and have contributed the code back. It's a great proof-of-concept that it CAN be done. However, I think if we focused on how to best implement this functionality and code that, we would be much better off. Think: if Jim Davidson hadn't put nearly as much thought into the design of AOLserver, would it be as good of an HTTP server as it is today? Shouldn't we put a similar level of study into the design of this change rather than just hacking it in "because it's easy to do this way ..."?
-- Dossy
-- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
-- 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.
-- Vlad Seryakov 703 488-2173 office [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/
-- 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.
