On Tue, Aug 17, 2004 at 08:55:26AM -0400, Dossy Shiobara wrote: > I see two "classes" of people using AOLserver for implementing non-HTTP > servers: > > 1) Low to medium performance requirements, short development timeline, > need for rapid development, programmers with low to average technical > expertise. > > 2) High performance requirements, highly skilled programmers, moderate > development timeline, scalability a major concern.
Dossy, this is all very interesting, but it also seems to have rather little to do with Zoran's original topic. Let's be blunt here: We have two proposed patches on the table for enabling AOLserver to be a multi-protocol rather than HTTP-only server. The question at hand is should either of these patches be applied, and if so, which one. So, Dossy, are you SERIOUSLY arguing that the correct answer is, "No, don't apply EITHER patch, because you can always roll your own from scratch in pure Tcl."? All your discussion so far can be easily taken to imply that, but I've honestly no idea whether that's your position or not. Please clarify. Finally, to head off the next and obvious question: "No, don't apply EITHER patch, because you can always roll your own from scratch in plain Tcl", is, IMNSHO, an totally bogus, unnacceptable argument. Yes, perhaps you COULD implement XYZ in Tcl only without any further integration into the existing AOLserver C facilities, and MAYBE it might even be almost as fast as doing it in C - it could even be true. But it's also almost COMPLETELY irrelevent to the question of, "Should we apply one of these two patches." Here's why: We already know that SOME hard-core AOLserver users find extended multi-protocol support in AOLserver, implemented in C, to be very useful. We know this because they went to the trouble to implement it themselves, are using it on their production sites, have discussed how it's important to them many times on this list, and have posted patches for public review and adoption. There is *NO* debate about, "Can this feature be significantly useful to at least some people?" We already know beyond any reasonable doubt that the answer to that is, "Yes!". 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. For example, arguments along the lines of: - The patches will make the code more complicated, uglier, bug prone, or harder to maintain. - We don't and won't have to do it, and we won't anytime soon, either. In short, it makes no sense to argue that, "There is no value to these patches." We already knows that they DO have value. What we may not know yet is, how much value, what might the costs and risks be, is the value worth those risks, and finally, what should we do about it. 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. Flexibility, power, and options are good. Giving people the option to code non-HTTP servers in C using AOLserver is GOOD. If people see real problems in these patches to do that, yes please, speak up, we need to hear about it! But the AOLserver project also has a LONG history of opposing useful, important patches (even bug fixes!) from outside developers, often for no apparent reason at all, and that sort of "not invented here" syndrome gets awfully tiresome. Please note, I'm NOT claiming that's what's going on here, right now. I don't really think it is actually, at least not yet. I just want to do my little bit to help keep us from heading off down that unpleasant road once again... -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- 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.
