Eckhard Lehmann wrote:
>>Well - with Subversion, we can rename files and maintain version
>>history, so let's just pick one and go with it. Barring something
>>better, mod_rivet22.c is fine - either that or put it in an apache2.2/
>>directory.
> The last is a good choice, I think. I have put all the files from src/
> into a new subdirectory src/apache-2, furthermore I moved the Apache1.3
> source files from src/ to a new subdirectory src/apache-1. I added a new
> toplevel Makefile.am in src/ and one Makefile.am in each of the both new
> subdirectories.
> configure.ac has some new macros now:
Great, this looks like a sensible way of organizing things... but I
think we could still improve it just a bit - some of the code, like
TclWeb.c and rivetCore.c is supposed to be independant of the server, so
it should go in the main src/ directory if possible... Actually, the
idea was that TclWebapache.c would be the template for TclWebapache2.c,
etc... But generally it looks good!
> - APACHE -- adds support for --with-apache switch to define the apache
> base directory
> - APACHE_INCLUDE -- adds support for --with-apache-include, to define
> the apache include directories. On some systems the include's may be not
> in the standard locations.. e.g. on debian they are
> in /usr/include/apache${version}.
> - APR_INCLUDE -- same as above for --with-apr-include. Both macros check
> the base directory that was set by APACHE.
> - APACHE_VERSION -- support for the switch --apache-version, either "1"
> or "2". Default setting is currently "2". sets the source directory to
> apache-1 or apache-2, so that rivet is compiled for the appropriate
> version.
Cool.
> However, I did not check whether this all works with Apache1.x...
I will do that this week.
>>The auto* stuff is a "pain in the ass"...
> Oh yeah :-/! I thought about a build system for Tcl extensions in Tcl
> all the time. It wouldn't be that complicated - but it would be
> reinventing the wheel...
Rivet originally had such a system (it's still floating around in
subversion, I think), but... people seem to look at it and think 'weird!'.
>>, so worry first about the C code, and the other stuff will follow.
> Well, I would like to have these things finished when I send the code to
> you and others, so that you/they can start to play with it immediately,
> without worrying about these nasty details.
Yes, having it build would be nice:-)
>>Do, however, separate the .c code into two different files, so that
>>you're not #ifdef'ing everything!
> No #ifdef's, I see, we agree on that :-). That would be IMO the poorest
> solution.
>>In short, if you want to make sure someone else has a copy of the code,
>>by all means, send it to me, but please, please discuss your work
>>publically on the mailing list!
> I have subscribed to the rivet-dev right now, and will summarize my work
> there, as soon as the confirmation emails are done. Meanwhile, I send a
> tar.gz file to you.
Great:-)
> Could you please check it into the subversion repository, if
> appropriate? I can do anonymous checkouts to see the changes from other
> people...
Let me get a chance to test it out some, and then I'll do that.
>>diff -n can handle new files. It's one of those programs that has an
>>option for *everything*, although no one knows them all:-)
> I will try it out :-).
> The only thing to do for configuration is, to extend the text/html mime
> type (in $APACHE/conf/mime.types) by the .rvt extension:
>
> ...
> text/html html htm rvt
> ...
I don't think that's quite right... we don't want the Rivet handler to
parse html files...does it try to?
> No other configuration is necessary, the application/x-httpd-rivet
> handler is also not necessary any more, for Apache2. I have not found a
> way to handle this, instead I got mystic crashes, when I set the request
> handler (request_rec::handler) to "application/x-httpd-rivet".
> I don't know whether this is the best solution, but it can be changed
> whenever we want.
Well, let's get it in subversion, and then go from there with
improving/extending it.
Thanks again:-)
--
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]
