Re: FastCGI Anyone???

davidhbigelow@simplifiedlogic.com wrote:
> Dave,
>
> This is a sensitive subject, but since you have brought this up two
> times now in separate discussions, I will lay out my position:
>
> You are absolutely right on both accounts. But when you say it is "not
> true" (indicating a desire to support), but then immediately come back
> with not willing to "sink a lot of my unpaid time into new development"
> - you are sending a *mixed* message to anyone that has the desire to
> use, or even get started with the lib.

What you said is that it would "not be supported", which is not true.
Bugs will be fixed, and new code may even be added. Also consider that
Karl Lehenbauer and Damon Courtney have made extensive contributions to
Rivet (Damon really kicked off the development of what was to become
Rivet from mod_dtcl a number of years ago), and may do so in the future,
so it's not just me doing Rivet - there is a community around it. And I
do have clients running on Rivet, so it's not like I'm just going to
walk away from it.

> Just like a job interview - What do you want to do in 2 years? Wait!
> Your not committed to this project?!?! Why again should we work
> together?

You're going to get roughly the same level of response from everyone out
there. The AOLserver guys probably have a bit bigger community, but
still... despite it being a brilliant language for the web, Tcl has more
or less lost that battle outside of some niches.

> I for one am more than willing to "pay" for something that works - and
> is supported. We pay for the TclDevKit because we know we can count on
> them to be there when we have a problem (and they are awsome!) - and we
> have even donated to projects that we use and want to let the developer
> know we appreciate their efforts (I even owe a few developers a dinner
> or two - which I will catch them up on very soon). We have even
> contributed code; although it is not near as masterfully done as what
> you and others do - but I try to support the community as much as the
> next guy, and evangalize Tcl at every turn - and our customers are
> outright impressed with what Tcl can do... (and usually purchase
> TclDevKit or adopt Tcl for various projects).
>
> But it is hard to put our eggs, and our customers eggs, in to a basket
> without knowing that there is a future for what we are trying to do.
> Specifically, we can't put out one level of awsome performance - which
> I think Rivet would provide; and then slow our users/customers down by
> a factor of 5-10x later because there is no active support or interest
> in supporting it at a future date, having to go back to old ways of
> doing things.

If you want a future with a big, active community, then you want PHP,
Java, or Ruby on Rails.

> I personally wish that this pacakge (Rivet) would become part of the
> TclLib and be in/supported for the long haul. It looks great, I have
> not tested it because I do not want to get my hopes up if it worked
> incredibly well.

tcllib is for pure Tcl packages. I think Tcl needs a tclClib too given
how successful tcllib has been, and to ship both tcllib and tclClib with
the core, but that's a whole different argument...

> I am sure that this point would raise tons of debate - and I am *not*
> looking for an arguement, only pointing out that it is hard to commit
> to something that does not appear (openly/realistically) to have the
> full support of evolving the technology as the technology evolves.
>
> What would you do if you were in my shoes?

I don't think I'd hazard a guess without knowing your requirements in
more detail. Rivet certainly isn't going to go away, and it works well
now. If you must have Apache 2.0, then perhaps Websh fits the bill. It
all depends on what you need to accomplish where, and with what constraints.

In short, both Rivet and Apache 1.3 are, to my knowledge, going to be
supported for a long while yet.

Unfortunately, there is a lot of code in the Tcl world that is held
together by just a few people (Jeff Hobbs and Andreas Kupries maintain a
ton of stuff between them, for instance), or no one at all, so truth be
told, Rivet, with several committers, is not doing too badly.

-- 
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/