Documentation

[Tom Krehbiel <to...@motorola.com>]

Tom Krehbiel <to...@motorola.com> writes:

(It's 'Rivet', BTW)


 >> I read through the Rivit documentation last night and really like
 >> the approach you have taken for commands. I looks like it would be a
 >> lot easier to write my code in Rivit than in PHP.


Great, I hope to make it easy, as well as complete.  I have worked
with PHP, and one of the positive things about it is that it is
relatively easy to get started with even for people without a CS
background.  Maybe they don't write beautiful code, but it's something
they couldn't have accomplished with a more complex system, and I like
that.


 >> Here are a few observations that may be helpfully.


 >> 1) The documentation was clear and easy to read.


Thanks!


 >> 2) The build instructions might be expanded a bit. I haven't done a
 >> build yet but I found myself wandering where things like tcl and
 >> apache needed to be relative to the rivit build directory.


They can be anywhere if you build Rivet as a loadable module (highly
recommended).  I added a note to this effect in the docs.


 >> 3) It isn't obvious to me how rivit is being run by the apache
 >> server. I'm aware of 2 methods of responding to page requests: tcl
 >> cgi process, tcl threads inside server. I've also heard about
 >> sub-process that are dedicated to processing particular request
 >> types. The documentation didn't clarify to me what environment the
 >> tcl interpreter was running in. The discussion about the exit
 >> command seemed to indicate that a thread was being used which didn't
 >> die when a transaction was completed.


The Apache web server works like this:

There is a master process that launches a bunch of child processes,
which each run select loops.  It adds or takes away child processes
depending on how much traffic is coming in.

What Rivet does is add a Tcl interpreter to each of those processes,
which is then used to process requests for .rvt or .tcl files.  So
it's pretty fast, because it doesn't have to launch new processes, or
even create new interpreters each time (it uses a namespace to hide
things in, so you have to be a little careful...can't just leave file
descriptors around, for example).

Does that explain things?

This covers things in depth:

http://www.math.uwaterloo.ca/~oadragoi/CS746G/a1/apache_conceptual_arch.html

 >> 4) I didn't understand the discussion of the session database
 >> interface. I'm familiar with RDMS systems but the discussion
 >> concerning table generation appears to be Postgres specific. I
 >> worked with Postgres a little a long time ago but don't remember
 >> enough to be sure. Examples using SQL would be better at this point
 >> in my opinion. I also don't understand your reference to DIO. I
 >> checked google and didn't get anything useful and the MySQL web site
 >> same result. Is DIO some type of API definition like ODBC?


Ok, sessions are pretty new, and Karl wrote the docs, so this one
would really be better addressed to the list (in reality, I would
prefer that all Rivet correspondence went there so that it's open to
the rest of the group, and archived so that future generations may
benefit from the wisdom dispensed there;-), but the short answers:

For now sessions have only been tested with Postgres.

DIO is like PerlDBI, but I still need to integrated those docs into
the main Rivet ones...

Thanks again,
-- David N. Welton Consulting: http://www.dedasys.com/ Personal: 
http://www.dedasys.com/davidw/ Free Software: 
http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org