cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Improving Sitemap and Flowscript
Date Sat, 23 Aug 2003 13:48:13 GMT

On Saturday, Aug 23, 2003, at 10:17 Europe/Rome, Christian Haul wrote:

> Stefano Mazzocchi wrote:
>> On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote:
> --------------------------------------------^^^^ Interesting,didn't 
> know that, thought to have been in Darmstadt ;-)

eheh, that means that you wrote that at 22:41 CET, not that you were in 
Rome writing it.

>>> I know, actions are not liked by everyone, but this is one of the 
>>> best applications for them.
>> are you suggesting we don't think about adding interception in flow 
>> because otherwise this would kill the only place where actions have a 
>> reason to exist?
> I'm going to ignore this comment.

Yeah, sorry, a little over the line.

>>> So, please provide a more convincing use case for the introduction 
>>> of AOP in Cocoon ;-)
>> Actions can be used as interceptors. It's not their only ability, but 
>> yes, it's possible and good actions do perform this way.
>> So, any use case that requires action-based interception, will work 
>> as nicely with flow interception.
>> What would we gain?
>> 1) action-based interception is a concern of the flow layer, not of 
>> the pipeline definition. i will never stop saying this, but actions 
>> should not exist in the sitemap realm, since they mix concerns.
> Well, probably yes. Although with very little organization, SoC can be
> achieved for this use case. But in general, you are right.

Yes, actions can be used well and flow abused. But the chance of 
abusing actions and using the flow well are much bigger, IMO.

>> 2) actions have a terribly poor error handling capability, even when 
>> used as interceptors, flow-based interception keeps all the 
>> functionality available at the flow level.
> Right, one can easily start a complex flow as error handling.

Exactly. Error handling *is* flow. Actions exhibit such a bad mindset 
that flow is the "right thing" and "errors happen rarely" that even the 
syntax reflects this (jumping *outside* the action tag, which is hacky 
as hell!)

>> 3) actions are hardcoded in the sitemap pipelines definitions. 
>> flow-based interception will allow to wrap existing code without 
>> needing to modify it or it will be possible to "remove" or modify 
>> interception without modifying the original flow code.
> Absolutely. I don't want to argue about AOP in general. It's just that
> your example is only touching the concept and for this we already have
> a solution.

sorry, mate, but this argument is the weakest I ever heard. In fact, 
any new information technology could be seen as touching a concept for 
which we already have a solution.

The problem is not finding *one* possible solution (a turing machine 
*is* a solution for every computational problem), but a better one.

Best is, obviously, a subjective concept and there is no objective 
metric so I won't even try to define one.

I'm presenting a solution that appears, to my personal taste, more 
elegant than the existing one. You might well disagree and I will 
highly respect you for this, but don't come up with the duplication 
argument because that's BS.

> This solution is not as elegant as AOP but it's here and
> it's usable.

So use it, for &deity;'s sake. I will never stop you from using it, but 
I will not lock myself into such an inelegant solution.

> We have some other features we all agree are really needed
> i.e. blocks. I'm not at all against AOP in Rhino. I just would like us
> to be more focussed on Cocoon, that's all ;-)

When I was at Sylvain's, Marcus asked us how we envisioned the ability 
to move global variables between different flows (i.e. flows that are 
not nested, but located side by side). This is an obvious requirement 
for sigle sign-on.

Several options were suggested by the three of us, but the one that 
appeared more elegant from a cocoon point of view was the use of an 
interception mechanism.

I'm not suggesting we add AOP to Rhino, I'm suggesting we add the 
ability to avoid concern crosscutting in the cocoon flow.

I can hardly think of anything more focused on cocoon than this.

>> I'll think about more juicy use cases tonight.
> Great!

1) bridging

This was suggested by something that happened to Ricardo. A company 
designed a web application that included some 300 servlets, all 
directly connecting via JDBC to a database. They implemented their own 
connection pooling, which was crosscutted all over the place. They had 
a threading problem and they were both lossing data and have zombie 
connections in the pool, causing memory and performance issues.

Ricardo, faced with the task of solving the issue, used interception, 
wrapped everything with his own connection pooling controller and 
released those connections that were not released by the pool.

80 lines of java code and a few days job. Hacky, granted, but wonderful 
effectivity/energy ratio.

In the future, many of us will be asked to fix flows that don't work as 
expected. Interception provides us another tool.

2) external resource control

this is an instance of the above. optimization of external resources 
used by the flow is *NOT* a concern of the flow itself, but a property 
of the context in which the flow is executed. For this reason, it can 
be implemented as interception.

Example of this are:

  1) connection pool control
  2) object persistence control
  3) external cache invalidation control (for example, a transparent 
proxy might be signaled to reload a resource)

3) monitoring

the creation of events that are not directly related to a flow but 
rather to its invocation. Examples of this are:

  a) logging
  b) debugging/tracing
  c) profiling
  d) concurrency analysis
  e) user profilation

4) context augmentation

when flow's behavior can be further specified by contextual data that 
might be defaulted if not present. Examples of this are:

  a) user authentication
  b) user personal parameters (style, mode, profile)

So, even if our users won't be more creative than I am (and I strongly 
doubt it!) things are already juicy enough, IMO, to provide a reason to 
implement interception in cocoon's flow.


View raw message