Having started the port of Rivet 2.0, I have to admit that I don't
have the time for it as well anymore.
But lately I thought about it, especially the restructuring issue. And
I thought it could be considered to put a new version of Rivet on top
of mod_tcl. Mod_tcl does bridge between Apache and Tcl, and it works
for Apache 2 as well. It also works on windows - some time ago I spent
an afternoon to port and compile it with Visual studio for Apache 2.2.
Maintaining mod_tcl and adapting it for new Apache versions is easy,
just because mod_tcl is very small and easy in terms of functionality.
It's basically a low level binding for the Apache API - not less and
not more.
So what Rivet essentially does is parsing the Tcl code in .rvt files
and I wonder if this could be implemented in pure Tcl on top of
mod_tcl? The advantage would be to have a low level layer in between
Rivet and apache. This makes abstraction easier and if something
changes in Apache, the only work would be to adapt it in mod_tcl.
Rivet would not be affected. Also, the big picture could be that it is
possible to run Rivet on top of tclhttpd or AOLServer.....
At this point, I would love to see Rivet become a web framework that
can sit on top of AOLServer, tclhttpd, or mod_tcl (with the
aforementioned work involved). I think we all have enough web building
experience to make something really cool that can sit on top of any of
these implementations. That would be my goal anyway.
Having looked at Ruby on Rails, I don't see anything so spectacular
that it couldn't be done in Tcl. Tcl was made for this kind of stuff.
It just takes work and the hands to do it, and those seem to be in
pretty short supply. In part due to lack of time, and in part due to
lack of interest.
Unless you have a truly dedicated team to work on a project, they
typically tend to flounder because what is there basically works well
enough, and other people don't have any more time than the people who've
already moved on.
Just some thoughts for someone who likes to dig into this - I would,
but I can not guarantee that (resp. when) I'll have the time for it.
If, and when, the time comes, we'll see what happens. 0-]
Damon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
