cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject portal engine / design
Date Sat, 08 Nov 2003 10:15:50 GMT

Hi team!

In my new day job I've been spending a lot time with Cocoon's portal
engine. Since we would like to have bookmarks and (for simple portals) 
be able to offload serving to a httpd, I spend some time looking deeper
at the internal mechanics and the event system.

It appears, that the publish / subscibe paradigm doesn't match the
problem at hand good enough. At least a number of things looked like
they were band-aids to make it fit.

Subscribers register themselves with the EventManager. However, in order
to do this, they need to live in the same component manager space as the
portal. This prevents e.g. startable + threadsafe components to
subscribe. As a consequence, the DefaultChangeAspectDataEventSubscriber
is hardcoded into the DefaultEventManager.

Another issue with pub/sub is, that layout elements need to be informed.
Unfortunately, for this they would need to be instantiated before the
event is published. Which cannot be guaranteed. The band-aid here is to
load layout elements when generating links (which means pulling in
a whole bunch of perhaps never needed layouts when displaying a page),
have an additional indirection, the above
DefaultChangeAspectDataEventSubscriber, and putting a hardcoded
target ie an object reference into the event.

This works, because currently the events themselves are stored inside
the session -- otherwise object serialization would be needed. In
addition, the interface does not require serializable event content.

Now, I would like to do the following:

Upgrade the pub/sub system with "persistent" delivery. IOW events
from the current request will be delivered to every new subscriber.
This way DefaultChangeAspectDataEventSubscriber can be discarded and
e.g. Layouts can subscribe themselves. Obviously, "persistence" would
end at the end of the request.

Another effect would be, that change events would be able to target
any layout that fills a specific role (the ID).

Have EventManager use SoftReferences (-> JCC) to register subscribers.

Add a name attribute to events and permit a subscriber to select
only events of a particular class AND a matching prefix for the name.
IMO the class resembles a JMS topic and the prefix would resemble the
JMS select. Putting this into the EventManager allows for optimizations
there and saves subscribers from implementing this logic.

Require events to be able to convert themselves to / from String.

I would like to have, but don't have a brilliant idea, yet, is to
be able to ask layout elements (or any other event subscriber) to
define their state relative to their default in terms of events.

Fire at will ;-)


C h r i s t i a n       H a u l
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message