Apache 2.0 TCL solution
Brian
Apache 2.0:
Ideally mod_tcl would be great but the tar.gz link on the
tcl.apache.org website is corrupt and cannot be untarred.
mod_dtcl has been superceded by rivet.
I tried compiling rivet with apache 2.0. Both Rivet 0.4 and 0.5 have
syntax errors when compiling apache_request.h (type 'table'
undefined???)
It is not possible to use tclhttpd.
Thanks
Brian
Robert Hicks
Ulrich Schöbel
Hi Brian,
try websh (http://tcl.apache.org/websh/), ir works with
apache 1.3, 2.0 and 2.2
Kind regards
Ulrich
Brian
sorry forgot to point out I am using Apache 2.0 on redhat 9. I will
have a bash (excuse the pun) at websh. Looks good!
Thanks Robert, Danke Ulrich
Gerry Snyder
> Can anyone recommend a server side solution to integrating tcl into
> Apache 2.0:
You should consider cgi.tcl
http://expect.nist.gov/cgi.tcl/
HTH,
Gerry
mark anthony
tcllib and seting an extension as cgi with apache and
using hash bang usr bin tclsh ??
cheers,
mark anthony
davidh...@simplifiedlogic.com
Any ideas on when this is going to be avilable?
Dave
Robert Hicks
Nothing is wrong with that! As if!
:Robert
David N. Welton
> whats wrong with the good ol' ncgi lib that comes with
> tcllib and seting an extension as cgi with apache and
> using hash bang usr bin tclsh ??
cgi is inherently slow because it's forked as a separate process each time.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
David N. Welton
> My vote is for RIVET!!!!!
>
> Any ideas on when this is going to be avilable?
Sorry to disappoint, but I don't think it's likely to happen at all.
I've started using Ruby on Rails for my own web stuff, and don't have
much hacking time in any case. As long as the competition was Java and
PHP... I had a good reason, but Ruby's not a bad language, and you get
so much stuff 'for free' with Rails that it's pretty overwhelming.
Robert Hicks
David N. Welton wrote:
> mark anthony wrote:
> > whats wrong with the good ol' ncgi lib that comes with
> > tcllib and seting an extension as cgi with apache and
> > using hash bang usr bin tclsh ??
>
> cgi is inherently slow because it's forked as a separate process each time.
>
Certainly, but depending on what you want to do with it cgi works fine.
Robert
Brian
forward to trying them out. but for performance and neatness i would
like an integrated tcl solution (and i want to show our web admin that
php or perl isn't the only solution).
it's a pity the mod_tcl tar ball is corrupt at the tcl.apache.org site.
websh looks fine though, compiled first time too. one question on
this: when loading mod_websh.so from the conf file apache cannot find
lib.tclx.x.so even in the modules directory. is there some workaround
to it like setting LD_LIBRARY_PATH or copying to /usr/local/lib. there
is nothing on the mod_websh website?
thanks
davidh...@simplifiedlogic.com
David N. Welton wrote:
> davidh...@simplifiedlogic.com wrote:
> > My vote is for RIVET!!!!!
> >
> > Any ideas on when this is going to be avilable?
>
> Sorry to disappoint, but I don't think it's likely to happen at all.
> I've started using Ruby on Rails for my own web stuff, and don't have
> much hacking time in any case. As long as the competition was Java and
> PHP... I had a good reason, but Ruby's not a bad language, and you get
> so much stuff 'for free' with Rails that it's pretty overwhelming.
>
I am not surprised - you have been flip-flopping on this package for a
long time.
What happens when Ruby looses it's luster? What will be the next - an
evntual ColdFusion and Flex-2?!?
I fail to see your technology competitive arguement for letting this
package die when you have companies like mine willing to pay you for
your expertice in this area and evangalize the technology to customers
around the world!
Rivet is a REALLY cool package, and solves a lot of elegant problems
relatvie to performance, session management, persistent database
connections, etc, etc, etc.... Not to mention it is very (very) fast
and easy to implement.
Does ANYONE want to pick up RIVET and run with it in Apache 2.0???
I personally would be happy with like functionality/performance as in
the Apache 1.3.x series - althrough the threads support would be cool.
Dave
Robert Hicks
davidh...@simplifiedlogic.com wrote:
> David N. Welton wrote:
> > davidh...@simplifiedlogic.com wrote:
> > > My vote is for RIVET!!!!!
> > >
> > > Any ideas on when this is going to be avilable?
> >
> > Sorry to disappoint, but I don't think it's likely to happen at all.
> > I've started using Ruby on Rails for my own web stuff, and don't have
> > much hacking time in any case. As long as the competition was Java and
> > PHP... I had a good reason, but Ruby's not a bad language, and you get
> > so much stuff 'for free' with Rails that it's pretty overwhelming.
> >
>
>
> I am not surprised - you have been flip-flopping on this package for a
> long time.
I am sure you didn't mean that the way it sounds to me.
:Robert
davidh...@simplifiedlogic.com
> > I am not surprised - you have been flip-flopping on this package for a
> > long time.
>
> I am sure you didn't mean that the way it sounds to me.
>
> :Robert
Actually - Yes I did... over time I have gotten that impression as to
Rivet's future.
Dave
Robert Hicks
But Rivet's future should not be tied to David. I don't think he would
want that. He has indicated over and over that he is too busy for the
Rivet project. That happens all the time in open source stuff. Either
someone picks it up (and like you I hope "someone" does) or it dies. If
I could program worth a beans in C, hell I would do it.
He helps when (and if) he can...I don't call that flip-flopping but we
may have different definitions for that term.
If you know of a way to fund it, why not contact ActiveState and see if
they can help? From following the posts for Rivet, I don't think it is
too far from being workable for Apache2. I think if it got to a
workable state that including Rivet with the ActiveTcl distribution
would be a great thing.
:Robert
davidh...@simplifiedlogic.com
> But Rivet's future should not be tied to David. I don't think he would
> want that. He has indicated over and over that he is too busy for the
> Rivet project. That happens all the time in open source stuff. Either
> someone picks it up (and like you I hope "someone" does) or it dies. If
> I could program worth a beans in C, hell I would do it.
>
> He helps when (and if) he can...I don't call that flip-flopping but we
> may have different definitions for that term.
>
> If you know of a way to fund it, why not contact ActiveState and see if
> they can help? From following the posts for Rivet, I don't think it is
> too far from being workable for Apache2. I think if it got to a
> workable state that including Rivet with the ActiveTcl distribution
> would be a great thing.
>
> :Robert
I totally agree with what you are saying...
I am pretty sure the question of Rivet coming under ActiveState has
come up before (probably from me) - I think the answer was TclHttpd...
or something else that is already out there like mod_tcl or WebSh -
WebSh (untill very recently) appeared to be "dead" also from a lack of
activity standpoint (web site did not appear to be updated for over a
long period as I recall) - and Rivet's embeddeness into Apache was a
more approachable I think for existing users of Tcl.
I truly believe that if the following things were in place form
ActiveState, Tcl would be in an awesome position to make a very strong
play for small business and enterprise development:
1) Rivet - Appache 1.3.x and 2.0
2) XML-RPC/SOAP 1.2 /1.3 -- from within Rivet!
3) tclodbc (curently supported - but thorwn in for completeness) - or
similar
(I would even include SNIT in this mix - having OO capabilities is not
a bad thing in this area - we use SNIT for an updated version of Don
Libes' cgi.tcl and it simplifies a lot of things).
If these Rivet and XML-RPC/SOAP components were in place together,
supported and agressively pushed - ANY Model View Controller Approach
to Rich Internet Application (e.g. flex-2, Laszlo, etc.) and aything
else for that mattter (e.g. HTML, XHTML, etc..) would be prme targets
for this type of implmentation.
With the simplicity of Tcl and the combined power of Rivet/XML-RPC/SOAP
- there is unbelievable potential for not only the small business
market - but also the enterprise environment (which we focus on
ourselves). A easy way to get from A-->B with an easy to use,
extensible and "fun" language.
This seems to be direction which the industry is heading (e.g. backend
logic and data pushing-to/constructing-displaying interactive
environments). I think Tcl is sitting there ready to strike - but
thowing in the towel because PHP and Java have higher
downloads/implementations is the wrong answer in my opinion.
Dave
Robert Hicks
davidh...@simplifiedlogic.com wrote:
<snip>
While I truly do love TclHttpd and think it is a really cool piece of
Tcl magic, it isn't in the same problem solving domain as Apache/Rivet.
Did anyone actually ask ActiveState I wonder...?
:Robert
Gerry Snyder
>> .... (.... we use SNIT for an updated version of Don
> Libes' cgi.tcl and it simplifies a lot of things).
Interesting! Is your version available somewhere? Is it free?
Gerry
Robert Hicks
Now that would be interesting...a cgi.tcl version written with Snit in
mind.
:Robert
davidh...@simplifiedlogic.com
for parsing input strings and the like. - but it is handy!
I wrote it to get around the globals that cgi.tcl wanted to use for
manging what it was managing - Rivet has some of this already built in
for parsing input. But I think some of it was not as elegant as what
SNIT would bring to the table.
I tested this with Rivet and it seemed to work wonders - given that
every session had it's own namespace, SNIT seemed to fall in line
without any issues relative to CGI. And enabled a more OO style of CGI
environment - which we use in some commercial apps and works very well.
Let me get a project off my plate and I will clean up a few things and
push it out for others to play with. Should not be long. Shoot me an
e-mail if you want to get it directly.
Dave
Gerry Snyder
> I have an "incomplete" version of this - it is basic stuff only mainly
> for parsing input strings and the like. - but it is handy!
>
>
> Let me get a project off my plate and I will clean up a few things and
> push it out for others to play with. Should not be long.
Great, Dave.
I look forward to it.
Cameron Laird
David N. Welton <dav...@dedasys.com> wrote:
.
.
.
>Sorry to disappoint, but I don't think it's likely to happen at all.
>I've started using Ruby on Rails for my own web stuff, and don't have
>much hacking time in any case. As long as the competition was Java and
>PHP... I had a good reason, but Ruby's not a bad language, and you get
>so much stuff 'for free' with Rails that it's pretty overwhelming.
.
.
David, I want to understand the situation clearly, and I hope you
can help. To the best of my knowledge, it remains true that Ruby
is NOT graceful about Unicode and thread-safety, right? I entirely
understand that many Web applications don't require those, and even
more don't *appear* to require them. I can see a place, though,
for Rivet, even in a Ruby-rich world.
davidn...@gmail.com
> But Rivet's future should not be tied to David. I don't think he would
> want that. He has indicated over and over that he is too busy for the
> Rivet project. That happens all the time in open source stuff. Either
> someone picks it up (and like you I hope "someone" does) or it dies. If
> I could program worth a beans in C, hell I would do it.
You understand the situation perfectly, Robert. The Apache Software
Foundation is a meritocracy, where anyone with an interest in the
software in question can get involved. Rivet was actually created in a
collaborative spirit - the original impetus to create a new project
from mod_dtcl and neoweb was from Damon Courtney, who did a lot of nice
work on it. The fact that people aren't getting involved is partly
what makes it less fun for me - it feels more like 'working for free'
than 'collaborating with other bright people', which is part of what I
like so much about open source software.
> He helps when (and if) he can...I don't call that flip-flopping but we
> may have different definitions for that term.
>
> If you know of a way to fund it, why not contact ActiveState and see if
> they can help? From following the posts for Rivet, I don't think it is
> too far from being workable for Apache2. I think if it got to a
> workable state that including Rivet with the ActiveTcl distribution
> would be a great thing.
I'd love to work on Rivet for money, and, not to put too fine a point
on it, would probably cost less than ActiveState. The problem is that
after 5 years of consulting, I got tired of it and accepted a full time
position last fall, and at this point in time am kind of enjoying a
steady income, even if it's less than what consulting pays at times...
In any case, the great thing about open source is that you can go to
who you want for work - I know I'd be happy to see the AS folks work on
Rivet, as they are fine engineers.
Also, everything else aside, Ruby on Rails really gives you a ton of
stuff out of the box. Working on my own, in my free time, I simple
cannot compete with what they have, and the gap keeps growing bigger.
Ciao,
Dave
davidn...@gmail.com
> >I've started using Ruby on Rails for my own web stuff, and don't have
> >much hacking time in any case. As long as the competition was Java and
> >PHP... I had a good reason, but Ruby's not a bad language, and you get
> >so much stuff 'for free' with Rails that it's pretty overwhelming.
> David, I want to understand the situation clearly, and I hope you
> can help. To the best of my knowledge, it remains true that Ruby
> is NOT graceful about Unicode and thread-safety, right? I entirely
> understand that many Web applications don't require those, and even
> more don't *appear* to require them. I can see a place, though,
> for Rivet, even in a Ruby-rich world.
There is probably a niche for it. I've written some about Tcl vs Ruby
here:
http://journal.dedasys.com/articles/2006/03/06/ruby-vs-tcl
Tcl certainly has some advantages over Ruby.
The kicker is that it's just not feasible to work on Rivet much, for
me. No money, not much participation from others, technology that's
not really new and exciting (I view learning as a form of
compensation). Let's say the economics (including intangibles like
'fun') of it just aren't working out.
Robert Hicks
Cameron Laird wrote:
> In article <44beacc1$0$30142$4faf...@reader4.news.tin.it>,
> David N. Welton <dav...@dedasys.com> wrote:
> .
> .
> .
> >Sorry to disappoint, but I don't think it's likely to happen at all.
> >I've started using Ruby on Rails for my own web stuff, and don't have
> >much hacking time in any case. As long as the competition was Java and
> >PHP... I had a good reason, but Ruby's not a bad language, and you get
> >so much stuff 'for free' with Rails that it's pretty overwhelming.
> .
> .
> .
> David, I want to understand the situation clearly, and I hope you
> can help. To the best of my knowledge, it remains true that Ruby
> is NOT graceful about Unicode and thread-safety, right? I
You are correct on those points and while it may not matter in the web
space, it does prevent me from wanting to use it fore "everything".
:Robert
davidn...@gmail.com
invested a lot of time in Rivet, so I feel compelled to respond.
> I am pretty sure the question of Rivet coming under ActiveState has
> come up before (probably from me) - I think the answer was TclHttpd...
> or something else that is already out there like mod_tcl or WebSh -
> WebSh (untill very recently) appeared to be "dead" also from a lack of
> activity standpoint (web site did not appear to be updated for over a
> long period as I recall) - and Rivet's embeddeness into Apache was a
> more approachable I think for existing users of Tcl.
Websh is pretty much in the same position Rivet is - Ronnie
occasionally does some work on it, and is always available for
questions and comments regarding the code, but I don't think it's
really "going anywhere new" as things stand.
> I truly believe that if the following things were in place form
> ActiveState, Tcl would be in an awesome position to make a very strong
> play for small business and enterprise development:
>
> 1) Rivet - Appache 1.3.x and 2.0
> 2) XML-RPC/SOAP 1.2 /1.3 -- from within Rivet!
> 3) tclodbc (curently supported - but thorwn in for completeness) - or
> similar
> (I would even include SNIT in this mix - having OO capabilities is not
> a bad thing in this area - we use SNIT for an updated version of Don
> Libes' cgi.tcl and it simplifies a lot of things).
I agreed with you until I started working with Rails. As long as the
'competition' for Rivet was PHP and Java, I felt there was a good
argument for continuing with Rivet, but Rails is really a jump up to
the next level in terms of web programming. You could copy it (mostly)
in Tcl, but I don't have a reason to at this point....
> logic and data pushing-to/constructing-displaying interactive
> environments). I think Tcl is sitting there ready to strike - but
> thowing in the towel because PHP and Java have higher
> downloads/implementations is the wrong answer in my opinion.
Rails is less popular than PHP and Java, actually, but it's not just
popularity that got to me. Rails is a very nice solution from the
technology point of view.
In another message you say:
"I fail to see your technology competitive arguement for letting this
package die when you have companies like mine willing to pay you for
your expertice in this area and evangalize the technology to customers
around the world!"
Honestly, I have had next to zero commercial interest in working on or
with Rivet. Were I to go back into consulting, I'm positive that I'd
have far more success with Ruby on Rails.
Part of the problem is that where Rails has had brilliant marketing,
Tcl's has been nothing short of disastrous, so with something like
Rails, that is good technology, hopping on the bandwagon is a pleasant
change from the "trench warfware" world of trying to defend Tcl.
A recent example:
http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3201127
Someone 'important' actually used Tcl for an important project, and I
don't even see anyone answering him in public.
I could go on, but I'm off to go enjoy my vacation...
Eckhard Lehmann
I had a look at the svn trunk yesterday... It is still far from
finished. The main tasks are
- fix the horrible autotools/configure breakage (maybe make a
completely new configuration)
- review and refactor the way that the rivet module is invoked
As for the first one, I was able to compile the module after I created
an Eclipse-CDT project from the sources, leaving everything out that is
not necessary. From this I can work, at least... For the second one, it
needs to be investigated how the .rvt content is handled and processed
in Apache1, and what exactly changes for Apache2, then just change the
relevant parts (easy, isn't it ;-)).
The project has *very* low priority for me, and it seems that I am the
only one who has put some work into it - that's why it will take a
clearly undefined and big amount of time until it is available.....
unless someone else wants to help out as well.
I would encourage everyone to help out, who has some time and C coding
experience - and wants to learn how to write Apache modules (or has
other interrests in getting rivet to run on Apache2). That would be
much more productive than complaining here, whereas I still like that
people complain - this way we see that Rivet is not useless and that it
makes sense to continue working on it.
Eckhard
Eckhard Lehmann
Robert Hicks wrote:
> While I truly do love TclHttpd and think it is a really cool piece of
> Tcl magic, it isn't in the same problem solving domain as Apache/Rivet.
It depends on whether you *have to* use Apache for some reason or
not... If Apache is running or has to run anyway, it is easy to add a
module like rivet.
But if you start from scratch, Tclhttpd might be the better solution -
if the goal is to write a web application in Tcl (and html, css,
javascript etc.). For this, Tclhttpd is *best* suited, in my opinion.
It has everything you need to achieve the goal: possibility of secure
connections, most powerful templating system I've ever seen, multi
threading, virtual hosts, cookies... and as I recently read, even
support for web services.
It is easy to install and easy to configure (in contrast to Apache).
And you can have a web application up and running in maybe a day, even
faster if you have some generic procedures for generating html (like
login forms, labeled entries, table generation etc...) or others. It's
not that hard to collect such procedures in a package.
However, I don't know how Tclhttpd behaves under heavy load, or what
security issues might appear surprisingly. Maybe people have
stress-tested the server and can say more about this?
Eckhard
Robert Hicks
The learning curve is less than easy for TclHttpd for *me*. This is due
to a couple factors. I am new to Tcl and new to TclHttpd. When I was
new to Apache/Perl there was a ton of stuff about creating a web app.
So I could do the "hello, world" web app program and then I could see
pretty much how things came together. I didn't find a "Creating a
simple TclHttpd app from scratch" type article.
Maybe that is a niche someone could fill. I am not talking about
anything complex, just something small to show what needs to go where
and stuff like that.
I have the Welch book and I have looked on the wiki but at my level of
knowledge those haven't helped. I am still working through it though.
: )
:Robert
Robert Hicks
Heh, the more I fall into the Tcl "world" the more I want to learn "C"
to be able to help out on things like this! : )
I think I will take a class or two at the local community college.
:Robert
Eckhard Lehmann
Robert Hicks wrote:
> The learning curve is less than easy for TclHttpd for *me*. This is due
> to a couple factors. I am new to Tcl and new to TclHttpd. When I was
> new to Apache/Perl there was a ton of stuff about creating a web app.
> So I could do the "hello, world" web app program and then I could see
> pretty much how things came together. I didn't find a "Creating a
> simple TclHttpd app from scratch" type article.
>
> Maybe that is a niche someone could fill. I am not talking about
> anything complex, just something small to show what needs to go where
> and stuff like that.
That is certainly something where you are right, absolutely. There is a
big lack of tutorial introductions and this keeps many people from
trying it out. I also think that Tclhttpd should have a website on its
own - at least a much better presentation on
http://tclhttpd.sourceforge.net/.
What I did was to walk through the examples and copied things from
there, they are nice and simple applications. But a tutorial would be
better, in that it is more public and "wetting appetite" - maybe this
is also a good article for www.tclscripting.com...
Eckhard
Robert Hicks
I upgraded the Oratcl site...I can do the TclHttpd one as well. That is
up to however controls it however.
:Robert