You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2006/01/15 09:22:58 UTC
checked in 2.0 code
Ok, I checked in Eckhard Lehmann's code... I haven't even tried to
compile it yet, but at least we can work from something in version
control. I probably made a few mistakes, but we'll correct them as we
find them.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: checked in 2.0 code
Posted by "David N. Welton" <da...@dedasys.com>.
Eckhard Lehmann wrote:
> 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.
No problem... thanks in any case for what you've done so far!
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: checked in 2.0 code
Posted by Eckhard Lehmann <ec...@web.de>.
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: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: checked in 2.0 code
Posted by "David N. Welton" <da...@dedasys.com>.
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: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: checked in 2.0 code
Posted by Eckhard Lehmann <ec...@web.de>.
David N. Welton schrieb:
> David N. Welton wrote:
>
>> Ok, I checked in Eckhard Lehmann's code... I haven't even tried to
>> compile it yet, but at least we can work from something in version
>> control. I probably made a few mistakes, but we'll correct them as we
>> find them.
>>
>
> Hi - I'm wondering if you've done anything with the 2.0 work since I
> checked in your code.
>
Hi,
no, I haven't got anything ready - not much time lately. 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?
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?
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.
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?
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...
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.
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 ;-).
Eckhard
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: checked in 2.0 code
Posted by "David N. Welton" <da...@dedasys.com>.
David N. Welton wrote:
> Ok, I checked in Eckhard Lehmann's code... I haven't even tried to
> compile it yet, but at least we can work from something in version
> control. I probably made a few mistakes, but we'll correct them as we
> find them.
Hi - I'm wondering if you've done anything with the 2.0 work since I
checked in your code.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org