> I'm sure they are small and useful commands, but I worry about adding
> more and more 'small and useful' commands in the future, to the point
> where it bloats. I don't want to set a bad precedent, so I am really
> in favor of looking things over command by command.
>
> > Lremove COULD be written in Tcl, but it's definitely a command
> > which benefits from C. The Tcl code to do the same amount of work
> > in C is much slower. I mean, if you REALLY want, we can load stuff
> > like this into packages or into command libraries (.so).
>
> Why not group together the pieces that fit together and make a small
> (but not ridiculously so) library, instead of one or two commands per
> .so?
I just don't wanna' end up having to load a bunch of crap in my
pages. Here's what I don't wanna' see.
<?
package require listcmds
package require stringcmds
package require othercmds
package require morecmds
?>
Some of the code I've done has been HUGE libraries of code. Sometimes
I only use a command once, but I'd hate always having to load libraries
to get one command.
> The question we need to ask is if they are things that everyone would
> want, if they wouldn't be useful as an external module. I guess I'm
> just worried that we'll keep adding a thing or two here and there and
> find ourselves with something the size of mod_perl. I mean, are they
> things that have to live in the core? Would a reasonable person find
> them indespensible (not just useful, but critical)?
True. I'm not really trying to bloat the module. I really, really
want to avoid that. It makes for really big, bad processes. We could
do what we did with NWS. It was actually a really nice idea. We had
the module, mod_neoscript.c. Then, we had neo8.3.0, which was a Tcl
package in C. When NWS booted, we'd load libneo8.3.so through a package
require command and get the necesary commands.
This was really useful for a couple of reasons. One, though we never
explored it, you could have run NWS without this library and left out
some bloat. Two, you could actually compile or load this library into a
standard Tcl interpreter and get most of the commands you had available in
an NWS page. We actually created a neotcl binary when you did a make.
Eventually, the plan was to do something like PHP has done where you can
actually compile a PHP binary that executes separately from the web and
use it on systems where you don't have sysadmin rights as a CGI.
>
> > It's already bloated with crap we really don't need.
>
> Oh? I'd be happy to unload more code, if possible.
All the apache_cookie stuff can be written in Tcl with little to
no work at all. The Tcl code would be maybe 50 lines of code and would
eliminate the 50k .o file that apache_cookie produces. This would
eliminate about 50k of bloat in mod_rivet.so.
> Thinking about things more, I guess what I consider core is: core Tcl,
> core Apache, and anything else for connecting and combining the two
> with the web server.
>
> I don't care if we even give people a default config that in turn
> loads a lot of this code, just so as those who want the "lean, mean,
> machine"
I think this is the best idea. Take both suggestions. Write all of
the C code into a Rivet package. One you can easily get with
"package require Rivet." I'm planning on adding in a PackageRequire
option to ServerConf that will do just that. Automatically package require
any package given into each interpreter. This will allow for admins to
totally setup each interp with what they consider the 'default' tools.
Everything else can be loaded on an as-need basis. Then, we'll just do
RivetServerConf PackageRequire Rivet
In our default configuration. It can be removed for anyone who wants
to, but it's there for regular users.
> Sleep time, it's late here
Where is here exactly? 0-]
D
