[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [RT] Improving Sitemap and Flowscript
From:       Christian Haul <haul () dvs1 ! informatik ! tu-darmstadt ! de>
Date:       2003-08-27 9:52:11
[Download RAW message or body]

On 26.Aug.2003 -- 06:43 PM, Stefano Mazzocchi wrote:
> 
> On Monday, Aug 25, 2003, at 10:10 Europe/Rome, Christian Haul wrote:
> 
> >On 23.Aug.2003 -- 03:48 PM, Stefano Mazzocchi wrote:
> >>
> >>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:
> >
> >>I'm not suggesting we add AOP to Rhino, I'm suggesting we add the
> >>ability to avoid concern crosscutting in the cocoon flow.
> >
> >After reading Nicola Ken's message I believe this discussion is void
> >but I still would like to explain my position as it appears it hasn't
> >been clear enough.
> >
> >I've started using flow very shortly after the javascript incarnation
> >arrived and I love flow. That is 1+ years using flow. I believed that
> >adding AOP to Rhino (which happens to be the javascript engine in
> >Cocoon) is beyond the scope of this project. Now you explained you
> >don't want to do that but only add it to the invokation of flow
> >functions. I believe that is a poor solution and does not provide
> >enough usefulness to solve any of your examples but the authorization
> >one.
> 
> I can hardly disagree more. When you have function interception you 
> have all you need to implement layers of invocation (and some people 
> call those layers "aspects", but I don't). This solves all the issues I 
> previously listed (including, yes, AAA).

Stefano, could you *please* explain what you are talking about? It
appears that every time I try to rephrase your intentions you say, you
are talking about a different thing.

According to your mails, you don't want to
 * add aspects to Rhino
 * add interception only to flow invocation

Where do you want to add your interception then??

> >However, as I said above, after reading Nicola Ken's mail I believe
> >this dicussion is void because it appears AOP in javascript is as easy
> >as saying "aspect". In addition, I believe his proposal for aspects in
> >the sitemap is balanced and very interesting. We should follow this
> >idea further.
> 
> I think we are talking about two different things here.

Indeed, Nicola Ken's mail contains to different concepts. The first
reads like a solution for aspects in javascript while the second is a
completely new proposal.

The reference to AOP fun with javascript is great.
The proposal is very interesting.

> One thing is layering flow, another thing is layering pipeline 
> definitions.
> 
> If you allow me to remove actions from the picture just one second, 
> you'll see how layering pipeline definitions might allow you to 
> simplify (or ease reuse) of pipeline definition fragments, but you also 
> understand how this is not going to help you on things that touch 
> resource flow rather than resource production.

This is no either-or situation. Why can't we have Nicola Ken's
proposal and use the Aspects.js he references as well?

> Note: I stay away from the name "aspect" because it's a overhyped 
> concept and too blurry to be used as a meaningful terminology because 
> it means different things to anybody.

Adding new names does not help either.

IMO is the problem of aspects in flow solved by the existence of Aspects.js
see http://freeroller.net/comments/deep?anchor=aop_fun_with_javascript

	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
[prev in list] [next in list] [prev in thread] [next in thread]