Re: [Modus-devs] Some general Modus comments to start with

[Sean A C. <se...@co...>]

On Tuesday, Nov 5, 2002, at 08:05 US/Pacific, Nathan Dintenfass wrote:
> I've gotta run out, but just a quick note . . .

I'm on BART, but just a quick note . . . :)

> Yes, agreed.  The notion of the "persister" in Modus is a move towards
> abstracting the persistence layer away from the contentObject API 
> itself
> (though, the baseContentObject has some convenience methods that pass
> through the persister).

Excellent! I wasn't clear from our earlier conversations whether that 
was indeed a guiding principle for you or not.

> Right now, each instance of the baseContentObject
> has its own reference to a persister (which in the current "build" 
> literally
> creates a new instance of a persister!!), and each contentObjectType 
> will
> have will have the ability to say which persister it wants to use (any
> persister must extend and "implement" the basePersister).

Yes, that makes sense.

> I do think that
> before 1.0 we need to move away from having a separate instance of a
> persister in each contentObject instance, but I am not sure if the 
> developer
> should need to worry about the persister -- that is, it seems very user
> friendly to be able to just say pressRelease.save() and have that deal
> internally with passing this to the persister.store().  Would you 
> disagree?

Well, the problem with that is that it means each content object 
instance must inherit from a class that knows how to save() and load() 
and so on. It's precisely this overhead that I'm suggesting we try to 
avoid. As Jeremy has discovered, object instantiation times are 
affected dramatically by inheritance and the # of methods.

Furthermore, there's actually a problem with inheriting from a class 
that knows about persistence - in fact there are two main (design) 
problems:
1. it forces all your content objects to be persistable (or at least 
know about the persistence machinery)
2. it precludes making a content object from something that inherits 
from some other base type

Let me explain those:
1. all content objects have save() and load() methods (because their 
base class has them) but you may want transient content objects - so it 
raises the question of what the default implementation for those 
methods is (as you say, you can have a range of persisters).
2. is the bigger issue. Suppose I have a vehicle component and I 
derived car and train from that. I can't easily make a persistent car 
if I need to inherit from some content object base class. This is why 
C++ has mixins and why Java has interfaces. You need a way to blend the 
implementation of one entity (car in this case) with the *interface* of 
another (content object in this case).

My suggested approach - making persistence a *service* - allows you to 
side-step this. I can easily make my car object persistable by creating 
an XML descriptor for it (externally) and then binding it into the 
persistence system dynamically. Sure, it means you can't save 
honda.save() and instead you need to create a carPersister (binding in 
the car XML descriptor) and then say carPersister.save(honda) but that 
isn't really a big hardship - yet it buys a lot of flexibility AND it 
removes the per-instance overhead of the persistence mechanism 
(methods, metadata, inheritance).

If CF had real interfaces, I wouldn't be as worried about this from a 
design point of view. If CF was higher-performance in its OO support, I 
might also concede this point on the grounds of simplicity. But neither 
of those are true so I'm going to stick to the idea of 
persistence-as-service (and would push for presentation-as-service too).

Besides, a plugin-based architecture like that is very flexible and is 
well-enough documented in the literature that developers shouldn't find 
it too alien (note that Fusebox MX uses a plugin architecture, much to 
my surprise - and delight!).

> Well, they may load faster on the server, but then the Flash movie
> has to "load" -- the perceived time on MANY pages (including the home 
> page)
> at macromedia.com is well over 1 second, no??

Yes, in fact our target for load time is well over a second - for a 
fully-loaded, interactive page (I don't have the thresholds on hand). 
However, what we are talking about with Modus is the time it takes to 
load individual objects. A very common scenario on a website is a 
summary page that displays, say, twenty items for the user to scroll 
through. If it takes Modus 500ms to load an object and render two or 
three fields (title, date, author for example), then that page will 
take well over TEN SECONDS to load in total. I would say that we should 
be aiming for a system that can load and render a 50 item summary table 
in around 5 seconds. That's a combined load and render time of just 
100ms per item.

"I can smell your brains!"
-- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html