|Subject:||Re: checked in 2.0 code|
|From:||Eckhard Lehmann (eck...@web.de)|
|Date:||Apr 25, 2006 12:36:53 pm|
David N. Welton schrieb:
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).
For most things TEA is fine, IMO. Automake introduces further complexity, and the different version & dependency issues are horror. TEA always worked for me when I did Tcl/Tk extensions so far, on both platforms where I work on (Ubuntu and WinXP/msys). It might be not as automated as the full set of autotools - but as long as it provides out of the box what it is supposed to, I see no reason to use something different.
However, with Apache modules the situation is different. The code is more complex, and it is not a Tcl extension - moreover it is an Apache extension (of course ;-), which uses Tcl. After some thinking about it, I agree with you in the above, the current setup is correct. When the macros are fixed everything should go ok...
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.
I feel that I won't have the time to hack on Rivet in the near future. There are other things that need to be done - regarding mostly some Tk/GUI stuff. This is also the area where I have the most benefit from right now... As I said in one of the postings in December on c.l.t, I don't work in Web development at this time. That's why I don't know exactly what is needed there, and I don't have a real benefit from Rivet. This might change in the future, and then I will be much more motivated to work on Rivet/Apache2, even completely alone ;-). The work that I did so far was purely driven by interrest in how the Apache API works and in the internals of Rivet, not from the fact that I actually need Rivet. When I could - resp. have to - use Rivet in my every day work, this would be a more fertile ground for long time interrest in the project.
Sorry if I don't do anything on the project in the next time... but be sure that I will stay tuned and probably jump in again, later.
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 think Rivet should resemble something of Tcl - easy to install, easy to use, no unnecessary overhead, flexibility and elegance. It should somehow separate from the overengineered and overcomplicated stuff that you get everywhere. It must be fun for web developers to use it and fun for administrators to install and maintain it. This could be hard to get with too many external dependencies - let the admin of some web server like to have a different Tcl version installed than the one Rivet needs - or let him not want to have external Tcl at all... the thinking of these people is often centered on "too many programs introduce too many security holes" (which is quite understandable). I am strongly convinced by, and defender of, the starkit/tclkit philosophy and binary distributions. I feel that self compilation and complicated installation procedures are always a hassle for everyday users... and that a binary that encapsulates it's functionality, to place at the right direction, is the best of all installation mechanisms. But I don't what is the best way for Rivet...
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!
Great, hopefully it will be picked up and done. I would do it, if I was a student (which implicates that I would have the time to do it ;-).