[Seaside] Prevayler

Avi Bryant avi@beta4.com
Mon, 18 Mar 2002 00:50:01 -0800 (PST)


On Mon, 18 Mar 2002, Cees de Groot wrote:

> +++ The idea, by the way, is not new. If you look at Squeak Webserver
> (some .at URL, forgot which one), it logs all calls to the webserver
> as a transaction log, and does a snapshot by doing an image save every
> day (now, *this* would be cool with Seaside - Avi, why didn't I think
> of this before? That could be a matter of hours to hook this in,
> shouldn't it? You probably could rip the necessary code from Squeak
> Webserver). In effect, the web requests are used as Command objects.
> When you crash the image, it'll replay all the web requests in order
> to restore state. +++

Yeah, I thought about this at one point.  No reason it wouldn't work, of
course, except that you have to make sure to snapshot every time your code
changes (hmm, another drawback for Prevayler in a Smalltalk
environment...). Maybe I'll try hacking out a JournaledSession subclass or
something.  Ideally it would be paired with some clock hackery so that
timestamps, etc, came out right.  However, in any real world situation
where you're interacting with external systems like an RDBMS, this would
be trouble... it only takes one html element more or less to completely
change the meaning of a Seaside url.

> Therefore, the best persistence engines I've used have a clearly
> defined low-level mechanism - you register objects manually, you start
> and commit transactions manually, you know how to get to the database
> root, you handle indexes manually, etcetera. On top of this, it *may*
> provide a 'transparent' layer that automatically registers changed
> objects; on top of this, it *may* cooperate with e.g. a specific web
> environment to provide for automated transaction handling.

Agreed.  This is how the GOODS client I've been working on does things.
I haven't gotten any comments on that, by the way, although I have to
admit I was just looking at it again today and getting some very flaky
behavior I'll have to track down, so maybe everyone just got frustrated
with it in the first five minutes ;-).

> I've come to the conlusion that the Smalltalk 'Object'/'Class'
> implementations are simply too low-level to support complex business
> objects, and you need to pull it to higher levels anyway by adding
> metadata, using type patterns, etcetera - the biggest challenge here
> is to wrap it all in a class browser that is still as accessible as
> 'normal' Smalltalk code (presumably with a toggle methods/attributes).

You've said something about this a few times, and I'm still not entirely
sure what you mean.  I'll look at Connectiva, but do you have time to give
a brief rundown of what you're thinking?

Cheers,
Avi