portal engine / design

[Christian Haul <ha...@informatik.tu-darmstadt.de>]

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 ;-)

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: portal engine / design

[Christian Haul <ha...@informatik.tu-darmstadt.de>]

Carsten Ziegeler wrote:
> Christian Haul wrote:
>>
>>Still, DefaultChangeAspectDataEventSubscriber is a hack since components
>>should subscribe themselves instead of this proxy.
>>
> 
> Yes, it's a hack and yes components should subscribe themselves, but data
> objects are not components and therefore shouldn't subscribe! E.g.,
> layouts, coplet data etc. are "only" data objects and not components and
> therefore imho they shouldn't subscribe. You can send an event to
> a managing component but not to the data itself.

OK. What would be the managing component for a layout? The layout 
factory? Or the profile manager? But then the factory (at least the
default factory) would need to (a) keep a reference to all layouts
which it doesn't and (b) know how a layout behaves which it ....
doesn't. Actually, the renderers know that. So, renderers should
subscribe? They don't have a link to the layouts they render, the look
up works the other way around.

Mmmh, they could store the event until a layout comes by that matches
this event. :-|

>>>><SNIP/>
>>
>>So you agree with the assessment on pulling in layouts and event targets?
> 
> No :)

Then I would really like some comments on this. You know, without docs
it's not really easy to understand the ideas behind it.

> As I said above, I'm absolutely against adding logic to the data
> objects, like the layout.

So it's the renderer, then?

>>>>Require events to be able to convert themselves to / from String.
>>>
>>>This is already implemented I think somehow, but you can't require
>>
>>I believe you are talking about EventConverter-s. These are a bit
>>difficult to do since they would need knowledge of event internals in
>>order to convert them to / from strings for example. It really should
>>be the task of an event to convert itself.
> 
> An event is only data (= message). We discussed this topic in length
> during the design phase and honestly I can'T remember why we choose
> this way :) Have to think about it...

This works fine for intra-request messages. Inter-request is different.

>>>it for every event. Think of inter-coplet communication where one
>>>coplet sends an event to other coplets with a whole bunch of
>>>information.
>>
>>Ah, I see. There might be events that are never send to the client but
>>stay on server-side. They are created and consumed during the portal
>>setup phase. IMO it would be sensible to introduce two classes of
>>events, then. "event-is-attachable-to-link" and "server-side-event".
>>The former must be able to convert to/from string and the latter need
>>not.
> 
> Personally, I don't like all this conversions. The current approach
> avoids costly serialization and is independent from the events.

It's the only way I see to have bookmarks or even think of going static.

>>However, I don't think any event should be "targeted" at a specific
>>subscriber instance. This is not the business of an event publisher
>>(see ChangeAspectDataEvent, IMHO this is bad).
> 
> The event is not targetted at the aspect data, but at a component that
> is able to do something meaningful with this event which is in this
> case change some data.

Granted. Still, I don't like the object references in a 
ChangeAspectDataEvent. This is hackish. Big time hackish.

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

RE: portal engine / design

[Carsten Ziegeler <cz...@s-und-n.de>]

Christian Haul wrote:
> Carsten Ziegeler wrote:
> > Christian Haul wrote:
> >
> >>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.
> >
> > No, this is not true :) The DefaultChangeAspectDataEventSubscriber is
> > actually a hack as it was the fastest way of getting it done. A better
> > way would have been to make the EventManager configurable with default
> > subscribers or to place the DefaultChangeAspectDataEventSubscriber
> > "somewhere elsed and let it subscribe by itself".
> > Each component can subscribe, regardless in which CM it is defined (at
> > least in theory).
>
> Still, DefaultChangeAspectDataEventSubscriber is a hack since components
> should subscribe themselves instead of this proxy.
>
Yes, it's a hack and yes components should subscribe themselves, but data
objects are not components and therefore shouldn't subscribe! E.g.,
layouts, coplet data etc. are "only" data objects and not components and
therefore imho they shouldn't subscribe. You can send an event to
a managing component but not to the data itself.

> >><SNIP/>
>
> So you agree with the assessment on pulling in layouts and event targets?
No :)

>
> >>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.
> >
> > Hmm, not sure if this is a good idea - have to think about it.
> But anyway,
> > you can change this by choosing a different implementation (your
> > "persistent"
> > one) for the EventManager without changing the current portal
> > behaviour. It's an add-on then.
>
> Well, yes. But since it removes the need for the
> DefaultChangeAspectDataEventSubscriber band-aid, I would want to change
> the behaviour of eg layouts to subscribe themselves. And the bahaviour
> of renderers to emit events that don't carry object references. This
> would lead to duplication of large sections of the current portal
> engine if done as add-on.
>
As I said above, I'm absolutely against adding logic to the data
objects, like the layout.

> >>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.
> >
> > This is already implemented I think somehow, but you can't require
>
> I believe you are talking about EventConverter-s. These are a bit
> difficult to do since they would need knowledge of event internals in
> order to convert them to / from strings for example. It really should
> be the task of an event to convert itself.
>
An event is only data (= message). We discussed this topic in length
during the design phase and honestly I can'T remember why we choose
this way :) Have to think about it...

> > it for every event. Think of inter-coplet communication where one
> > coplet sends an event to other coplets with a whole bunch of
> > information.
>
> Ah, I see. There might be events that are never send to the client but
> stay on server-side. They are created and consumed during the portal
> setup phase. IMO it would be sensible to introduce two classes of
> events, then. "event-is-attachable-to-link" and "server-side-event".
> The former must be able to convert to/from string and the latter need
> not.
Personally, I don't like all this conversions. The current approach
avoids costly serialization and is independent from the events.

> However, I don't think any event should be "targeted" at a specific
> subscriber instance. This is not the business of an event publisher
> (see ChangeAspectDataEvent, IMHO this is bad).
The event is not targetted at the aspect data, but at a component that
is able to do something meaningful with this event which is in this
case change some data.

Carsten

Re: portal engine / design

[Christian Haul <ha...@informatik.tu-darmstadt.de>]

Carsten Ziegeler wrote:
> Christian Haul wrote:
> 
>>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.
> 
> No, this is not true :) The DefaultChangeAspectDataEventSubscriber is
> actually a hack as it was the fastest way of getting it done. A better
> way would have been to make the EventManager configurable with default
> subscribers or to place the DefaultChangeAspectDataEventSubscriber
> "somewhere elsed and let it subscribe by itself".
> Each component can subscribe, regardless in which CM it is defined (at
> least in theory).

Still, DefaultChangeAspectDataEventSubscriber is a hack since components
should subscribe themselves instead of this proxy.

>><SNIP/>

So you agree with the assessment on pulling in layouts and event targets?

>>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.
> 
> Hmm, not sure if this is a good idea - have to think about it. But anyway,
> you can change this by choosing a different implementation (your
> "persistent"
> one) for the EventManager without changing the current portal
> behaviour. It's an add-on then.

Well, yes. But since it removes the need for the 
DefaultChangeAspectDataEventSubscriber band-aid, I would want to change 
the behaviour of eg layouts to subscribe themselves. And the bahaviour 
of renderers to emit events that don't carry object references. This
would lead to duplication of large sections of the current portal
engine if done as add-on.

>>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.
> 
> This is already implemented I think somehow, but you can't require

I believe you are talking about EventConverter-s. These are a bit
difficult to do since they would need knowledge of event internals in
order to convert them to / from strings for example. It really should
be the task of an event to convert itself.

> it for every event. Think of inter-coplet communication where one
> coplet sends an event to other coplets with a whole bunch of
> information.

Ah, I see. There might be events that are never send to the client but
stay on server-side. They are created and consumed during the portal
setup phase. IMO it would be sensible to introduce two classes of
events, then. "event-is-attachable-to-link" and "server-side-event".
The former must be able to convert to/from string and the latter need
not. However, I don't think any event should be "targeted" at a specific
subscriber instance. This is not the business of an event publisher
(see ChangeAspectDataEvent, IMHO this is bad).

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

RE: portal engine / design

[Carsten Ziegeler <cz...@s-und-n.de>]

Christian Haul wrote:
>
> 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.
No, this is not true :) The DefaultChangeAspectDataEventSubscriber is
actually a hack as it was the fastest way of getting it done. A better
way would have been to make the EventManager configurable with default
subscribers or to place the DefaultChangeAspectDataEventSubscriber
"somewhere elsed and let it subscribe by itself".
Each component can subscribe, regardless in which CM it is defined (at
least in theory).

> <SNIP/>
> 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.
Hmm, not sure if this is a good idea - have to think about it. But anyway,
you can change this by choosing a different implementation (your
"persistent"
one) for the EventManager without changing the current portal
behaviour. It's an add-on then.

>
> 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.
This is already implemented I think somehow, but you can't require
it for every event. Think of inter-coplet communication where one
coplet sends an event to other coplets with a whole bunch of
information.

Carsten