On Wed, 15 Sep 2010, Damon Courtney wrote:
Date: Wed, 15 Sep 2010 08:52:26 -0500
From: Damon Courtney <[email protected]>
To: Rivet_dev <[email protected]>
Subject: Re: Moving forward
I think one of the biggest advances in the potential for the use of
Rivet by others has been the creation of a Linux RPM and a FreeBSD port
of Rivet 2.0.
While I enthusiastically welcome further Rivet development, successful
efforts to grow the user base will yield more energy and more people
who are willing to contribute.
That being said, I don't particularly know where to go from there.
I'm not sure I know where to go either. 0-] I'm just working with it and
starting to find places where it could be improved, that's all. I think
you're right about getting new users and new energy, but not a damn one
of us knows how to do that. If we did, one of us might have been able
to save Tcl somewhat. David has complained of this point many times.
We're just not marketing people. How do you market a language to
someone? Tcl is much easier for novices to grasp, but its setup means
that you have to have an Apache server implementation with the ability
to compile modules in. That's not something a novice is going to have.
They're going to be setup on a simple hosting service that probably has
PHP built in. It's the default choice for a lot of people because it's
always there.
I'm open to suggestions, but I've given up caring about what people want
to work on my projects. If I want to work on them, I work on them.
The people who care about the project and use it will always contribute
to it here and there. But until someone has a need for something, the
project will push along doing what it does without problems. It doesn't
mean the project is dead, it just means there's not much to do with a
stable release that works really well and does the job.
D
<0.02$>
While targetting novices is appropriate for growth in the long haul, it is
more likely that a fresh book specifically on Tcl/Rivet/Apache will handle
the fledgling web developer (NOVICE???).
In terms of widespread short term adoption of Rivet by pros, a couple of
things must change. I'd actually done a couple of commercial web sites
using Rivet, but reluctantly abandoned it when Dave Welton left the scene
for Ruby/Rails (but before the recent resurgence, and the Apache 2.x
support).
I'd suggest looking closely at a popular javascript framework, perhaps
jQuery, and putting together the underpinnings of an integrated
Ajax/backend model with theming. Tcl handles a number of databases quite
nicely, and it must be able to support several (SQLite, MySQL and
Postgresql at a minimum) -- which IT DOES.
The original Rails model required that the application must fit the model
provided (simplistic integer keys etc etc), and I haven't looked at it
since. A means of using a simple JSON object (instead of XML) to describe
complex database architectures would give Rivet a huge advantage in the
custom web sector. Also, by downloading schema object to the browser,
rich forms with data checking could be offloaded to the client ...
The MVC approach, using XML/HTML/CSS, the DOM model and front and back end
processing is powerful, but the state of the art today is still a bit of a
mess. If Rivet were to provide a browser agnostic unified view of the
mess which has defined the HTTP/Ajax/Database delivery model, adoption
would soon follow, IMHO. I mean, what's the competition -- PHP??? ick!
The proof of concept would be a Wordpress/Joomla/Drupal like CMS which is
themeable, easy to modify, has an understandable architecture, and has a
web app look and feel -- but the architecture is more important than the
CMS itself, and it must build upon an elegant one which is knowable by an
intermediate web developer.
To sum up: Rivet must adopt an elegant frame work architecture which
makes it dead simple to develop compelling platform agnostic rich
multi-media web applications. That's all.
Rob Sciuk
</0.02$>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
