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!
http://wiki.apache.org/general/SummerOfCode2006
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 ;-).
Eckhard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
