Apche/Tcl + Rivet = Supa Fast CGI...

[davidh...@simplifiedlogic.com]

Ladies and Gentlemen,

My eyes have been opened to the capabilities of Apache/Tcl+Rivet
recently. It is an amazing package with very cool capabilities for
dynamic Web Sites via CGI.

>From a performance standpoint, I think Rivet (which is an embedded Tcl
interpreter within Apache - just like php) shows tremendous promise for
mass appeal - especially when coupled with an easy to use, and
extend, language like Tcl.

We setup our environment within Windows XP Pro and Apache 1.3 and found
immediate performance increases (which we expected) just by having Tcl
registered within Apache.

The ability to register our libs and pre-load other libs (e.g. tclodbc
and others) within Rivet on Apache Startup was a pleasant surprise in
capability and results in our being able to make connections to
databases faster and more efficiently than using Conventional CGI
approaches (e.g. entire environment launched and libs loaded with each
page).

The results:

Near instantaneous database calls, page rendering and delivery of
information. Our test environment:

Rivet 0.50
Apache 1.3
Tclodbc 2.3
Oracle 9i database (~0.5 million records)
SQLINT 5.0 (our internal lib for dynamic SQL)

Very, very, cool stuff. And I encourage others to become familiar with
this project and support its continued evolution into Apache 2.0 and
beyond. The framework is very well designed and planned. If your
customers and end-users only permit certain web servers to be ran,
(e.g. Apache, IIS, etc.) - Rivet gives you some interesting options
for building web sites and applications with Tcl - apparently, without
sacrificing performance.

Kudos to the Rivet Team! (and thanks for porting to Windows/Apache)

Dave

[jima]

Has anyone any idea on how Rivet compares to OpenACS ?

[David N. Welton]

jima wrote:
> Has anyone any idea on how Rivet compares to OpenACS ?

OpenACS is big and does a whole lot of stuff, and is built on top of
AOLserver which is itself big and does lots of stuff. AOLserver is a
nice system. Rivet aims to be small, fast, easy to start with and
interact well with Apache. A bit more like PHP - which thousands upon
thousands of people got started with because it was so easy to start with.

Ciao,
--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

[Robert Hicks]

Is there a reason you are using Tclodbc and not Oratcl? Just curious...

Robert

[Acacio Cruz]

My quest for a "good" Tcl web solution is long and does not augur good
things for anyone else seeking the same. I even got involved with the
tclhttpd project providing testing, packaging and some documentation
support (coding being difficult due to time limitations).

The reality is that, for an "average" case (ISP hosting), it is quite
difficult to go the Tcl-way. mod_tcl or Rivet are not supported,
tclhttpd requires a port to be opened and a "server" installed which is
also not usually supported.

Rivet looked very promising but the lack of Apache 2.0 support and no
perceived development effort made me steer clear of this. This whole
thread confirms my impressions, too, unfortunately.

I even tried to go the FastCGI way but that too has been left to go stale.

So, I am one of those that also opted (reluctantly!) to go the PHP way
because, after all, is not that horrible and it is EASY.

I still love and use Tcl anyway I can (first package to be installed in
any computer I touch) but there are some glaring holes that Tcl needs to
plug before it improves it's appeal:

1) Database connectivity. I know what you're going to say (Oratcl,
pgtcl, etc...) BUT is you take the *typical* user nowadays he will
probably be looking for MySQL. The MySQL package is *OLD* (last version
2004) and does not support the latest versions. Globally, database
connectivity is a mishmash of poorly maintained and inconsistent
interfaces, supporting rather old versions of Tcl and database versions
(Oratcl the notorious exception here).
TclODBC is 4(!) years old. It may work but I can hardly believe that
in over 4 years nothing has changed in the ODBC world or at least a few
bug patches. The lasting impression is of stale code.

2) Web interfaces. I mentioned above the major issues already. Just
would like to reinforce the need to make it *easy* for newcomers. It isn't.

I see a lot of excellent work being done but, even with ActiveState's
commitment to the language and Jeff's work, there is a lack of focus on
the priorities for newcomers to the language and making it easy for them.

For example, a *lot* of discussion is going around about the OO
extensions when we already have several OO extensions and some very good
(XOtcl). And yet, *none* is readily available for a newcomer to try.
[Itcl has a staleness feel to it]. I may be simple-minded in this but,
first, pick one OO extension and make it part of all the distributions
in every platform. Only after, go after the OO TIP work.

Final rant: I'm still trying to understand why, but why, did Jeff
decided to start a Mac OS X package (very good) but make it subtly
different (in packages) to the the Tcl Aqua BI distribution (BAD)?
Right now, I'm still trying to figure out what the differences are and
what is the rationale. It'd be much better I think to
adopt/continue/absorb the Tcl Aqua project into ActiveState than start
yet another consumer-confusing option. And, why not, extend the BI
concept across the board (sorely needed, btw).

I also know what you're going to say ("you can always contribute, code,
etc...") but that is a fallacious and easy argument (not everyone is/can
be a developer). Also, I believe not much work is required, just a
different look at priorities to address some of the base work required.
Just like Linux-desktop was a couple of years ago, uncouth, until a few
guys decided that polishing it was a priority to attract people and I'm
now writing this in a Ubuntu laptop which was EASY to install and
configure. Same approach is required for Tcl beyond what ActiveState is
already doing.

We could have used the Google Summer of Code and not one Tcl project was
proposed (Perl, Python and Mono had projects)
http://code.google.com/summerofcode.html

What I'm personally prepared to contribute:
- testing, packaging and some documentation work for Tcl packages in
Linux x86, Win 32 and Mac OS X environments (maybe Solaris 9 if I revive
my Ultra)
- Some basic Tcl coding (mostly bug resolution).

Regards,
-Acacio

PS: Final contribution: Latest SQLite3 loadable module for Mac OS X:
http://www.acacio.com/tcl/libsqlite3.2.7.dylib.gz

davidh...@simplifiedlogic.com wrote:
> Ladies and Gentlemen,
>
> My eyes have been opened to the capabilities of Apache/Tcl+Rivet
> recently. It is an amazing package with very cool capabilities for
> dynamic Web Sites via CGI.

>>From a performance standpoint, I think Rivet (which is an embedded Tcl
> interpreter within Apache - just like php) shows tremendous promise for
> mass appeal - especially when coupled with an easy to use, and
> extend, language like Tcl.

> Near instantaneous database calls, page rendering and delivery of

[David N. Welton]

Acacio Cruz wrote:

> Rivet looked very promising but the lack of Apache 2.0 support and no
> perceived development effort made me steer clear of this. This whole
> thread confirms my impressions, too, unfortunately.

Apache 1.3 works just fine on Unix, and if someone wants to do the 2.0
port, it's free software, so no one is stopping the effort.

Frankly, I hope people realize that, given the "staleness" you mention
below of other projects, that Rivet is doing ok in that it is still
maintained at all, and active in the sense of having a decent group of
people on the mailing list who answer questions, fix bugs, and so on. A
lot of Tcl code barely has that these days.

> I even tried to go the FastCGI way but that too has been left to go stale.
>
> So, I am one of those that also opted (reluctantly!) to go the PHP way
> because, after all, is not that horrible and it is EASY.

I've been fiddling with Ruby on Rails myself, and I'm impressed. The
language isn't quite my cup of tea, but after years of trying to push
Rivet, Tcl and so on, the idea of not having to struggle with
acceptance, and riding the wave of hype is very, very tempting.

> I still love and use Tcl anyway I can (first package to be installed in
> any computer I touch) but there are some glaring holes that Tcl needs to
> plug before it improves it's appeal:

> 1) Database connectivity.

Yep...

> 2) Web interfaces. I mentioned above the major issues already. Just
> would like to reinforce the need to make it *easy* for newcomers. It isn't.

Rivet is pretty easy to get started with, it's just not available on
ISP's, and wont be, because everyone wants PHP. It's the "demand side
economies of scale" thing, again.

> I see a lot of excellent work being done but, even with ActiveState's
> commitment to the language and Jeff's work, there is a lack of focus on
> the priorities for newcomers to the language and making it easy for them.

> Final rant: I'm still trying to understand why, but why, did Jeff

> decided to start a Mac OS X package (very good) but make it subtly
> different (in packages) to the the Tcl Aqua BI distribution (BAD)?
> Right now, I'm still trying to figure out what the differences are and
> what is the rationale. It'd be much better I think to
> adopt/continue/absorb the Tcl Aqua project into ActiveState than start
> yet another consumer-confusing option. And, why not, extend the BI
> concept across the board (sorely needed, btw).

This problem would go away, in part, if Tcl's default distribution were
the 'batteries included' version ala PHP and Python.

> I also know what you're going to say ("you can always contribute, code,
> etc...") but that is a fallacious and easy argument (not everyone is/can
> be a developer). Also, I believe not much work is required, just a
> different look at priorities to address some of the base work required.
> Just like Linux-desktop was a couple of years ago, uncouth, until a few
> guys decided that polishing it was a priority to attract people and I'm
> now writing this in a Ubuntu laptop which was EASY to install and
> configure. Same approach is required for Tcl beyond what ActiveState is
> already doing.

Fair enough. BTW, Rivet is available in Ubuntu because I'm also a
Debian maintainer and of course I packaged it.

> We could have used the Google Summer of Code and not one Tcl project was
> proposed (Perl, Python and Mono had projects)
> http://code.google.com/summerofcode.html

Through the Apache Software Foundation, I proposed an Apache 2.0 port
for Rivet, but there were no takers:-(

> What I'm personally prepared to contribute:
> - testing, packaging and some documentation work for Tcl packages in
> Linux x86, Win 32 and Mac OS X environments (maybe Solaris 9 if I revive
> my Ultra)
> - Some basic Tcl coding (mostly bug resolution).

That's a pretty good offer.

[Acacio Cruz]

David N. Welton wrote:

> Acacio Cruz wrote:
>
> Frankly, I hope people realize that, given the "staleness" you mention
> below of other projects, that Rivet is doing ok in that it is still
> maintained at all, and active in the sense of having a decent group of
> people on the mailing list who answer questions, fix bugs, and so on.

Just one observation/suggestion: I'd bump the next release version to
1.x. The 0.x number gives Rivet an air of pre-production/beta.

Also, it'd help if there were pre-compiled binaries for download for the
most popular OS's (Linux x86, Mac, Win32).

Let me know if you need me to produce the Mac version (I know you
already have easy Linux/Windows access).

-Acacio

[Robert Hicks]

There are Windows binaries available.

I would also like to put in my .02 cents. If you are going to use
Rivet, get on the list. They are wonderful at helping out when problem
arise. Just another area where Tcl'ers show their "quality".

Robert

[cyrille...@gmail.com]

Hello,

What is the tcl version and distribution you are using ? I'm currently
trying to setup an environment with Windows 2000, Apache 1.3.33, Rivet
0.5.

Firstly, I tried with ActiveTCL 8.4.11 (without threads enabled) and
all works right as long as there is no concurrent connections
(simultaneous users). In the case of simultaneous connections I face
Apache crashes.

Then I tried ActiveTCL 8.4.11 (with treads enabled) and in that case
even an plain HTML rivet template doesn't work, I have the following
error :
can not find channel named "stdout"
while executing
"puts <PRE>"
(procedure "::Rivet::handle_error" line 6)
invoked from within
"::Rivet::handle_error"

Thanks in advance

Cyrille VIVION

[davidh...@simplifiedlogic.com]

Couple of reasons.

1) tclodbc gives us the ability to rapidly change database types
without changing code or approach.

2) We looked at oratcl when we were concerned about performance, oratcl
is definaly a better solution for oracle, but did not seem to have a
performance advantage for our queries over tclodbc (again there are a
lot of variables in that test - and I am pretty sure that the oratcl
version is probably a lot better than tclodbc, but for our needs
tclodbc did the job).

Dave

[davidh...@simplifiedlogic.com]

where and how do you get on the list?

Dave

[Robert Hicks]

davidh...@simplifiedlogic.com wrote:
> where and how do you get on the list?
>
> Dave

mailto:rivet-dev...@tcl.apache.org

Robert

[Jeff Hobbs]

Acacio Cruz wrote:
> TclODBC is 4(!) years old. It may work but I can hardly believe that
> in over 4 years nothing has changed in the ODBC world or at least a few
> bug patches. The lasting impression is of stale code.

Actually, the last commits were 19 months ago. I would not
be so certain that the ODBC world has changed all that much
in the last few years, but this is another case of having a
newer version, just no release files for it.

> For example, a *lot* of discussion is going around about the OO
> extensions when we already have several OO extensions and some very good
> (XOtcl). And yet, *none* is readily available for a newcomer to try.
> [Itcl has a staleness feel to it]. I may be simple-minded in this but,
> first, pick one OO extension and make it part of all the distributions
> in every platform. Only after, go after the OO TIP work.

I'm not sure that is so incongruous with the current attempts
in TIP #257 to "pick one".

> Final rant: I'm still trying to understand why, but why, did Jeff
> decided to start a Mac OS X package (very good) but make it subtly
> different (in packages) to the the Tcl Aqua BI distribution (BAD)?
> Right now, I'm still trying to figure out what the differences are and
> what is the rationale. It'd be much better I think to
> adopt/continue/absorb the Tcl Aqua project into ActiveState than start
> yet another consumer-confusing option. And, why not, extend the BI
> concept across the board (sorely needed, btw).

This has been discussed already, but Daniel went to extra
efforts for just the Mac platform. For the most part,
ActiveTcl is still limited to what works well across
platforms, though we do add some platform specific bits (like
tcom on Windows and tclMac* on Mac). He also had the ability
to add things like ssl (tls) that we simply can't due to
export restrictions.

> I also know what you're going to say ("you can always contribute, code,
> etc...") but that is a fallacious and easy argument (not everyone is/can
> be a developer). Also, I believe not much work is required, just a
> different look at priorities to address some of the base work required.
> Just like Linux-desktop was a couple of years ago, uncouth, until a few
> guys decided that polishing it was a priority to attract people and I'm
> now writing this in a Ubuntu laptop which was EASY to install and
> configure. Same approach is required for Tcl beyond what ActiveState is
> already doing.

I agree, and I stated as much at the conference last week.
However, I can only do so much. Being the developer type, my
time is best spent making the code solid. Mark Roseman was
great to assist in updating the website, but more assistance
is necessary there to make the intro experience for others
much better.

> What I'm personally prepared to contribute:
> - testing, packaging and some documentation work for Tcl packages in
> Linux x86, Win 32 and Mac OS X environments (maybe Solaris 9 if I revive
> my Ultra)
> - Some basic Tcl coding (mostly bug resolution).

That would be most welcome. Send me email if you have any
specific questions about what to target.

> PS: Final contribution: Latest SQLite3 loadable module for Mac OS X:
> http://www.acacio.com/tcl/libsqlite3.2.7.dylib.gz

Did you know that ActiveTcl already included SQLite 3 across
all its platforms, OS X included?

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

[Robert Hicks]

Jeff Hobbs wrote:
> Acacio Cruz wrote:
<snip>

> I agree, and I stated as much at the conference last week.
> However, I can only do so much. Being the developer type, my
> time is best spent making the code solid. Mark Roseman was
> great to assist in updating the website, but more assistance
> is necessary there to make the intro experience for others
> much better.
>

What kind of assistance is needed? Is there a list of things that need
to be done? Or is it in someones head and only comes out it situations
such as this?

Robert

[David N. Welton]

Acacio Cruz wrote:

> Just one observation/suggestion: I'd bump the next release version to
> 1.x. The 0.x number gives Rivet an air of pre-production/beta.

We'll give it a 1.x number when it deserves it. The code is good, but
the installation stuff needs help. It works for me, but apparently it
doesn't work for other people. Unfortunately, my ability to fix things
on other people's computers is limited, so some of these people will
have to step forward and do things like create patches, and work with us
to debug their problems.

> Also, it'd help if there were pre-compiled binaries for download for the
> most popular OS's (Linux x86, Mac, Win32).

Certainly!

> Let me know if you need me to produce the Mac version (I know you
> already have easy Linux/Windows access).

If you can get it to compile and explain to other people what the
problem is, or help figure out why it's not compiling/running, that
would be a good start for MacOS X.

Thanks,

[Robert Hicks]

Actually, if i read the dev list right, we need a Windows guy as well.

Robert

[David N. Welton]

Robert Hicks wrote:
> Actually, if i read the dev list right, we need a Windows guy as well.

It would be great to have a windows guy or two.