Rick, Hopefully you recognize the difference between your private hacking and forcing everyone to adopt your hacking by applying it to the core code. It should be expected that AOLserver developers will need changes to the core code to allow their application to function more efficiently, but that doesn't mean that the changes are universally helpful.
But, your application may expose a flaw or a limitation in the core code. This is the benefit of applications, the tend to test the assumptions used to develop the environment. But the change to the core has to preserve the original functionality, and extend it, or make it more general. Usually these types of changes have the quality of simplifying the core, not making it more complex. These types of changes are easy to identify, their solution seems so obvious. Anyway, the way this simplification usually presents itself is in a modularization of the code, something like a plug-in type functionality. This is the type of core changes that interest me, in general, higher level APIs remain unchanged, but you get different implementations between some lower level and the higher level, stable API. This type of refactorization is difficult and requires expert knowledge, and it should be obvious that we can't find that type of expertise from developers who are interested in generic API development. The point is to change the core so that you can add your new functionality as a module. So without tough requirements like yours there is nothing to inform us of the limitations of the core code, but once these limitations are exposed there is another step: you need to work at perfecting the core without making it more complex. Over time, what should happen is that the core code becomes less complex and supports more features via add on modules. I know we are not there yet, but future work will not be successful unless it is informed by real world applications and aims at simplification of the core. I know I have a (possibly well deserved) reputation for resisting change. This is not exactly what bugs me. What usually cause me to complain is the missing step of simplifying the core to support the new functionality. The basis for this complaining is easy to explain. The core code works very well for everyone except for the person who discovers otherwise. Any changes that complicate the core code only benefit this person and make it more difficult to maintain for everyone else. Even if it adds functionality, until yesterday, nobody cared about it. So, simply adding new functionality is not a benefit if it doesn't come with some refactoring, or maybe correcting a true deficiency. The contribution is not the new functionality, the contribution is refactoring, correcting deficiencies, and simplification. These things help everyone, the new functionality only helps you. But there will always be applications which require core changes which are unique. This doesn't mean the application is flawed, or that the AOLserver API is lacking, this is why we have open source. Sometimes developers come up with unique problems that demand unique solutions. The AOLserver core is also a great starting point for such development, because it remains clean and mostly rational. But every API has limitations, this is a requirement. In answer to your true observation: "Stability has its costs as well as its benefits" Actually stability is the ultimate goal, instability has no benefit for those who are happy with the current code. My argument is that development must focus on stability. If you take into consideration the effect of what you want to do on everyone else, the result will be positive. If, instead, you seek only to add new functionality, to move the ball forward, to contribute something that you think is important, the result is likely to be not so good. Community development means that you respect the current situation but want to improve it without disrespecting the current situation. But the cost of blind stability is really stagnation and death. My real gripe is that, correctly or not, I perceive many attempts to change AOLserver as leading to instability, mostly due to a lack of effort. What I am interested in is 'dynamic stability'. That means that change is sometimes expensive to do right. AOLserver has reached a point of development where the idea of a small change is the hallmark of ignorance. There are no small changes at this point. tom jackson On Tuesday 08 April 2008 18:46, Rick Cobb wrote: > Tom, I'll take a small issue with your: > > A > > quick look at all the modules in CVS suggests that this is the best > > way to > > > contribute code, not by hacking on the core. > > I think that's an effect, not a cause. My company stopped submitting > changes well before I came to it (2003) because the core changes it > needed were not acted on (i.e., accepted). We still don't believe that: > * Conns should belong to a single thread > * Authentication and authorization belong in the same module > * A deployment will only use one authentication protocol > (Ns_ConnReturnUnauthorized) > * System logging shouldn't have hooks for external system log > consolidation (syslog, mod_log_spread...) > > At least the first of those got some action in 4.x, but we've still had > to modify the core and drivers to get our connection count up where we > want it on Windows (>10000 established sockets; that may help folks > understand why 1 thread == 1 socket doesn't work well for us). > > (I'm aware OpenACS has a fine set of workarounds (sorry, modules and > deployment conventions) for the second and third problem, but I can't > use 'em (and don't read the source for 'em) since it's GPL'ed.) > > But we don't submit our changes, because going through the process you > suggest (which I admit, we use an abbreviated form of internally) would > double our technical management overhead, and have us working on use > cases we frankly don't ever deal with (e.g., virtual hosting). > > Would we take that overhead if our developers didn't think they'd end up > spending as much time arguing (sorry, "motivating their changes") with > folks who won't affect our bottom line as they do with their colleagues > & customers? I don't know; I think we'd be more likely to. > > I second your thought that setting direction would be good. But I find > it very easy to hear your input as "nullity is a good direction". > > Stability has its costs as well as its benefits -- > -- ReC > > -----Original Message----- > From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf > Of Tom Jackson > Sent: Tuesday, April 08, 2008 4:52 PM > To: [email protected] > Subject: Re: [AOLSERVER] Minor facelift to aolserver.com > > On Tuesday 08 April 2008 13:52, Rick Cobb wrote: > > Well, it's certainly compliant :-), but I suspect Mr. Jackson would > > object. > > > If there's one thing aolserver ain't, it's "beta". > > Well, at least he has a goal to achieve, and once we attract 'people' > who are > interested in developing beta grade software, we will surely get there > very > quickly. > > A cute logo isn't going to attract the level of developer who would be > able to > maintain AOLserver, much less provide a useful enhancement. > > But like I said: why not figure out what needs to be done...first. > > IMHO, by advertising the stability of the AOLserver API, you will > attract > users who would otherwise be correctly scared off by constant hacking. > > Another thing which might attract interest is if our current community > members > would write a brief application note explaining how they use AOLserver, > and > why they chose it over other potential platforms. Additionally, we could > > catalog sites known to run on AOLserver. My guess is that developers who > have > similar interests and motivations or similar problem solving skills as > current community members will be attracted to the community. Given the > fact > that there have been only a handfull of CVS commits in the last year, I > would > venture to guess that most community members are happy with the current > codebase, and that means that new community members will probably be > looking > for a mature project which allows them to focus on their own > application, at > least at first. Then, they may contribute a module which extends > AOLserver. A > quick look at all the modules in CVS suggests that this is the best way > to > contribute code, not by hacking on the core. > > Change for the sake of change will scare off any sane developer, we > don't > charge for upgrades, please remember this fact. > > tom jackson > > > -- > 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. > > > -- > 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. -- 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.
