Eckhard Lehmann wrote: > no, I haven't got anything ready - not much time lately.
Neither have I:-( > Just some > thoughts... > I checked out the code from subversion once, but got massive trouble > with the autoconf thing. I was not able to run ./genconf.sh, autoconf > and make failed too... Maybe I did something wrong with my macros :-(. > Anyway I think this should be refactored completely. Best thing is maybe > to make it TEA compliant and add some macros for finding the right > apache configurations? I think what we have in there is basically correct. TEA is kind of crappy in my opinion - the rest of the world seems to use the full auto* group of tools rather than just TEA, and TEA is this low-level mess in any case, not something high level like apxs or similar tools (Ruby and Python both have ways of compiling stuff automagically IIRC). > The API changes in Apache can make a grown man cry - complete changes > from 1.3 to 2.0, another change from 2.0 to 2.2... nothing really > documented; pure chaos. You really learn to appreciate the documentation > and consistency of Tcl here. It might be more appropriate to have > completely different versions of Rivet for the different Apache > versions? At least two different versions for Apache 1.x and Apache 2.x? I think that the work we did to separate out the part that talks with the web server (mod_rivet.c and TclWebapache.c) is sufficient to isolate the core (rivetCore.c) - if it's not, we should look at changing it. The idea is that Rivet should be able to run in different environments. You might look at how Websh does things - it compiles for Apache 1, 2, and also CGI (a standalone executable). That said, yeah, Apache 2 is completely different (look up "second system effect") and it's not an easy undertaking. It is gradually replacing Apache 1.3 installations, though, and in some ways it is a bit nicer. > Those autoconf issues are worst and I think it has to be decided and > done first. It is no fun to spent more time on fixing silly m4 macros > than on bugfixing the program itself. Yes, I realize that... I suggested to the Tcl folks years ago that they provide build support tools of some sort, but it hasn't happened. The existing system is the result of a lot of effort on my part to learn and beat the auto* tools into place, with some help from Karl et al. > If you agree, I put the apache-2 stuff together in a TEA compliant > module and add appropriate macros for apache headers and libs. In my > opinion it doesn't make sense to continue working on the module before > this is sorted out and ready to go. Still you might have better ideas? Well, if it helps you to work on it, I guess we could create a subdirectory or something where you basically have total control, so that you can at least get the C hacking done. Then we could worry about proper auto* support later. I know quite well that C hacking is fun, whereas auto* hacking is a soul-draining exercize in frustration:-) > For the module itself, I need a deeper understanding of what is going on > in Apache during request processing. It is not done right at the moment, > e.g. the handlers and mime type configurations from the config file are > completely ignored. I think the module is not hooked in at the right > position, or something is missing... There are apache lists where you can ask after these kinds of things, as well as IRC channels on irc.freenode.net that sometimes have people who know a thing or two. > Another issue we should discuss is, whether we should built the Tcl > interpreter into the module and thus get around external dependencies. > mod_tcl is doing it that way, AFAIK, and Tcl is predestinated for those > kind of things. It would make things much easier in the long term, > especially for admins and users. It should be possible but not the default. On a modern system like Debian, Tcl is a shared library in order that it *be* shared. It's a better way of doing things in terms of resources. > I don't hesitate to continue working on the project - and I see > potential for Rivet to get a larger user and developer base (even easier > if Rivet can provide some things that PHP does not provide, or not in > that quality). But we have to sort out some things first and point in > the right direction. Well, also it would be good to be not the only one > who works on Rivet/Apache2 ;-). I don't have a lot of time right now:-( BTW, if anyone is a student, I think I can get Rivet added to the google summer of code program via the Apache Software Foundation. $4500 isn't that much compared to some jobs, but it's not a bad amount to finish up the port! http://wiki.apache.org/general/SummerOfCode2006 -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
