mail at marco-paga.de
Fri Feb 28 08:40:39 UTC 2003
Your post is interesting. What you think is good. The whole prevayler
thing is very Java like because I come from java and because of this I
can't often see all the great features of smalltalk.
Avi Bryant wrote:
>I've been watching the work on SPrevayler with a cocked eyebrow, because I
>have to admit that I find it an extremely clunky approach, at least in its
>Java incarnation. Stephen's suggestion to combine it with REPLServer is
>interesting, but I think goes in the wrong direction - we don't want to be
>logging doIts (isn't that what the .changes file does anyway?), and we
>don't really want to be logging commands, we want to be logging message
>There are a couple of steps that I think could be taken to make the
>Prevayler approach more "smalltalky" and more manageable. The first is to
>get rid of Command objects and replace them with Message objects. That
>is, wrap a proxy around the PrevaylerSystem that implements DNU to capture
>and log any messages sent to the system before forwarding them on (if
>you like, you can wrap these in a Command object before serializing them,
>but you'll only need that one class of Command). This gets rid of the
>ridiculous duplication of having to implement a Command class with
> aSystem someMessage: ...
>for every message on System.
You want me to create a porxy that stands before the system. The proxy
gets all the messages that should be send to system and serializes these
What you mean is just writing the Object>>perform: withArguments: to the
Do I have to put the logic into doesNotUnderstand: of the proxy class?
But in fact it stays the same. The prevalence layer is just used behind
the scenes. If using the above the prevayler would write the system as
usual just the commands are created hidden. We would have a command like
PerformCommand that keeps track of the sent commands.
Sorry for my pie-sized brain but I'm just a newbie to squeak.
>The second step is to maintain a weak dictionary mapping unique
>ids to any object that passes through this proxy as a parameter, so that
>these ids can be written into the log instead of the objects themselves -
>you only need to fully serialize the object into the log when the id is
>first assigned (and, of course, you should replace any objects that
>already have ids during this serialization, with an id marker).
This is not very useful in my mind. The outputs I use have a built in
mechnism for this. (
>At that point you'd have something halfway between Prevayler and an OODB -
>no transactions, still a single bottleneck for mutation, but much more
>flexibility in what your commands can look like and much less overhead in
>Marco, Stephen, thoughts?
More information about the Squeak-dev