[site-engine-dev] A silly mistake, a promising start and this week's challenge

[MJ Ray]

Hello hackers!

A special welcome to the new list members, including a few more from tsw,
which is the first web site using the code.  You really need to figure out
how to check out the code from anonymous CVS, as it'll be a couple more
weeks before I'm happy enough to start making tarballs.

There's a lot more to say, so feel free to ask questions to get me started
explaining bits of the system.  Until then, here's a quick summary of what
I've been hacking on since my last email:

There have been a few more code clean-ups and bug-fixes, so that's good. 
The fact that the bugs were there in the first place is probably a strong
hint that I should start work on the "test" collection before too much
longer.  These bugs were mostly found by tsw's tests of the code.  The worst
one was a bug in the bug reporting mechanism.  Ow!

Silly Mistake
-------------

That made me discover my first silly mistake.  One of the slowest parts of
any database-driven web site is opening the connection to the database, so
we should aim to only open one connection per page and use it throughout. 
Of course, once we move to an application server, then we can start doing
clever things like connection pooling and reduce the numbers yet further,
but that's a while off down the road.

Anyway, I've noticed that I've not been opening one connection per page. 
I've not even been opening one per object.  I've been opening one connection
for each method.  Yes folks, site-engine currently will make a database
connection when you check a user's password, and then open a second
connection when you save the article they just submitted.  This is not good.

There are two ways to solve this.  The first is to make the db-open function
look to see if we actually have a connection open already (probably in a
closure) and return that if we do, but then we need some sort of
"destruction" function in order to disconnect cleanly.  To do that, we'd
probably need to use something like GOOPS to let us do Object-Orientated
scheme and it'll slow us down further.  Not my favourite idea.

The second option is to open the database connection at the start of each
glue script and pass it into each database-using method.  I'm still not keen
on that, as then we have more work in the glue, which is the opposite of
what I want to achieve.

Maybe there's a third way to do this, but I can't see it.  Can you?

CGI changes
-----------

The promising start mentioned in the subject line is that the cgi module has
been moved off into its own collection.  It's split into two parts now, (cgi
input) and (cgi output), so scripts only need to load the input bit if they
want to parse user input (and most do, I think).  They've now been joined by
a third module, (cgi cookie) which sets and gets cookies.  This is likely to
be used by a (wse session) module later on, but more thought needs to be
given to architecturing it... maybe we should use path- or query-based
session IDs instead.

Right, to explain that: sessions are a way to store user data on the server
temporarily and get it back when the user next asks for a page, instead of
shoving it all in every HTML request, which you don't want to do for
passwords.  These are the three common ways of doing sessions:

query-based -- each URL has ?sessionID=a4hk23hjkyui23498sa on the end, where
that's a unique identifier.

path-based -- each URL has /a4hk23hjkyui23498sa/ in the path.  Looks
cleaner, but will be cached more readily.  That can be a good and bad thing.

cookie-based -- the browser is sent a cookie named "sessionID" or similar
with the identifier in it.  It sends it back on each request to the server
until it is unset.  The browser needs to support cookies, though.

I'm not really sure which is best.  What do you prefer?  Which have you
found works best in the wild?

Challenge of the Week
---------------------

I'm going to start laying down the gauntlet to get the help I need to make
this a kick-a system.  If you manage to complete a challenge, I'll put you
in the AUTHORS file as well as the changelog and you get my respect right up
until your next serious server-destroying goof.  TSWers, you can trade that
for a pint, probably. ;-)

I really need an smtp-send module similar to (wse nntp).  All it needs to do
is take some parameters and send an email by connecting to an SMTP server. 
The commands you need are "HELO wse" "MAIL FROM:<address@hidden>" "RCPT
TO:<address@hidden>" "DATA" and sending a valid email after that,
then "." and "QUIT".  You should be able to crib from the NNTP module which
does all the socket connection stuff.

Anyone up to the challenge?  Send emails of code to me or the list, as you
please.  Remember to "reply to all" to hit the list.

MJR
-- 
MJR