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.
-- Stefano.
