On Tuesday 02 October 2007 02:50, Gustaf Neumann wrote: > > I'm going to ask that the patch be removed and replaced with a module. > > i got the - wrong - impression that you (Tom) revised your proposal to > change > the patch into a module, when you realized, that the patch is NOT > implementing background delivery, but something much more simple > and generic.
I wonder how many times I have to repeat myself, but I'll try again: This 'simple' and 'generic' feature has nothing to do with ns_conn or how connections are processed in AOLserver. The patch and the module do the same thing, so what the code does is not of concern to me. It is an interesting feature. I wish there were examples of how to use it with plain AOLserver plus thread::transfer. What we are really discussing is your resistence to putting the feature in the correct place. And the reason for your resistence appears to be that it is too much work for you. Even with the module completely written and functional, that isn't enough. You want a special arrangement which saves you from having to undo the bad decision to patch AOLserver for two years, instead of writing a module. Maybe we should ask why it took two years to submit such a simple patch? I'm not interested in fame and glory or in saying 'use my module'. I'm trying to provide an example of how to contribute to the AOLserver community in a way which respects the extremely well developed API and the community. Imagine what the sources would look like if the goal was to just do it as easily as possible. There would be no ability to extend the server. Future maintainers would have to carefully consider every change as it might have difficult to detect consequences. There are lots of things which are inconvenient in programming. But we do them because in the long run they save us time and effort. The AOLserver sources provide a good example of how inconvenient good programming can be. Of all the talk about design patterns, I haven't ever heard about convenience being one of these patterns. Why should convenience be the criteria for adding new features to AOLserver? > Additionally, i would prefer aolserver and naviserver > to be as compatible as possible I prefer to advocate for AOLserver, not naviserver, OpenACS or Tcl. And in this case it would be nice if new code followed AOLserver coding norms. Maybe you can get naviserver to take out their code. The module I wrote at least compiled against their server, but nsd doesn't run on my 64bit laptop: web/navi $ ./bin/nsd -f -t sample-config.tcl [02/Oct/2007:10:37:45][6858.690331232][-main-] Notice: nsmain: Tcl version: 8.4.14 [02/Oct/2007:10:37:45][6858.690331232][-main-] Fatal: NsTclInitObjs: sizeof(int) < sizeof(long) Aborted 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.
