cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [C2] XSP and apects (was: log performance penalties)
Date Tue, 27 Feb 2001 12:01:25 GMT
Allan Erskine wrote:
> Thanks for the reply.  I a bit feel misrepresented on some parts - my
> fault though...(original message was one of these 5am moments
> of "clarity")...I've tried to redress this below; hopefully my suggestions
> won't appear quite as 'out there' this time...apologies to those that regard
> some of this OT....

Absolutely no need to apologize, Allan.

Really, I mean it: it's because of comments such as yours that evolution
takes place. It's a real pleasure for me (but I think I can talk for
everyone around here!) to partecipate in such friendly discussions.

Believe me, it's not as common out of this community.
> > > ----- Original Message -----
> > > From: "Stefano Mazzocchi" <>
> > >
> > > > Of course, the real solution would be to use AspectJ to code Cocoon,
> but
> > > > I'd rather wait until AspectJ stabilizes before moving to aspect
> > > > oriented programming. [for those of you who don't know what I'm
> talking
> > > > about, look at for more info on ASP for Java]
> > > >
> > >
> > > XSP seems nothing short of an aspect abstraction mechanism.
> >
> > Well, thanks for saying this. Interesting enough, this is exactly what
> > Ricardo and I were discussing a months ago privately, the only problem is
> > the XML syntax which is very unfriendly with code.
> >
> > So, while I agree with your vision, I'd suggest to be careful: XSP was
> > designed with SoC in mind as well as ASP. So it's very likely that you

                                 <typo>read AOP!!</typo> 

> > percieve both as the same, but it's logically wrong since XSP (at least
> 1.0,
> > the current) is targetted to server page generation, not to code
> generation
> > in general.
> This had occurred to me.  Since XSP and
> logicsheets were designed with SoC in mind, might I have confused aspects
> with concerns and pointed out the startlingly obvious?

No, this is not what I percieved.
> Well, hopefully not!  Here's where I was coming from...
> Assuming a "concern" in this context is taken as delimiting a
> broad area of interest, such as presentation or application logic, I
> believe that my use of the word aspect is actually closer to what it usually
> means in AOP, namely a feature that crosscuts many system components.

Well, "concerns" and "aspects" are different things, the second more
granular than the first. 

Visual example: if you give me a "concern" as a 3D object, I percieve
its "aspects" as its projections (shade) to a plane. Of course, there
are an infinite number of projections of a 3D object onto a 2D plane
(you just have to move the plane around the rotate its normal!).

So, there are "areas of interest" (concern islands) that share the same
concerns, this automatically forces the sharing of the aspects these
concerns convey.

But different concern islands might share the same aspects... in fact,
it's pretty easy to come up with a list of aspects that are shared by
all concerns. For example, the concept of "useful" is an aspect, not a
concern because it applies to concerns and discriminates them, but
doesn't uniquely identify one.

This is the terminology I use so hopefully this would remove some
terminology problems that might emerge.

> The difference between implementing aspects in a general purpose programming
> language (like Java) and implementing aspects in a restricted purpose, but
> extensible language (like XSP) lies in the manner in which aspects are
> modularised/captured.

> In aspectJ, the aspect construct is provided as a modularisation unit for
> crosscutting concerns.

Well, no, this is not how I see it (but it's a personal opinion, not an
objective truth): the above seems to indicate there is no difference
between a concern and an aspect, being one the technical implementation
of the other.

I'd like to keep the two things separated: my concern might be the
visual presentation of information, the aspects of the problem are
"usability", "friendlyness", "politeness", "visual coherence", "error
support", etc...

If your concern is writing application logic, aspects are "visibility"
(logging), "stability" (concurrency, memory management), "security",
"modularity", "coherence", "simplicity", "reusability", "longlasting",

Many of this "aspects" are implicitly bound into the programming
language, or the programming paradigm: this is what 'high level' means,
more aspects are taken into consideration by the programming language or
contract design.

In fact, design patterns are aspects frames: they give you the "shape"
of the object and if you use that shape, you automatically have some
shades, thus some aspects.

Java is so good at this because it has the "interface" concept: without
interfaces, Java would be just another OOP language. So, it is entirely
possible to associate one aspect to one interface and use multiple
interface extension as a cure to the ugly OO multiple inheritance.

Guess what? This is exactly what we designed in Avalon: the only
existing AOP framework that doesn't require Java syntax modifications.
Look at Cocoon2 in

public class Cocoon 
      Contextualizable {

It is evident that pure OOP practices are becoming obsolete in those
fields where concepts become too abstract to be 'synthetized' into
behavioral objects.

But Java was *NOT* designed with AOP in mind (only the interface concept
has influence from this late accademic research). So we are left with
the question: can it be turned into a full AOP language?
> In XSP, what appears to happen is that markup is chosen to
> represents and encapsulate what would otherwise be a crosscutting feature,
> that is to say,
> markup-constructs are being deliberately chosen to capture aspects.
> (regardless of whether the
> crosscutting feature/aspect represents a complete concern area).

This is correct. I resonate with this view.
> And so my proposition is just the simple observation that as well as being
> pivotal in separating the concerns in cocoon's "pyramid of contracts" model,
> XSP markup is flexible enough to capture aspects that would crosscut the
> system if hardcoded.  This is why I'm a *fan* of XSP, and would seek to
> expand and refine it's role.
> I hope this sounds reasonable...

Yes, entirely. But this is where I see the problems: just like Java was
not designed for multi-dimensional separation of concerns in
programming, XML wasn't either!

XML is the first widely known model that allows multi-dimensionality
(with namespacing) and since XSP makes heavy use of this, it seems
logical to percieve an increased functionality and aspect orientation in
a fully multi-dimensional syntax.

But this rings a bell in my head: are you sure that it's really XSP that
you like? or rather a collection of "aspects" that XSP itself has?

Would it be better to take the good part of these aspects and carefully
craft a syntax extension for the Java language, much like the AspectJ
folks are doing, rather than use XSP a skeleton to provide
multi-dimensionality to mono-dimensional programming languages?

Hey, look: I don't have an answer for this! I've been fighting with the
limitations of the OOP paradigm since I proposed the creation of Avalon
three years ago and I've been very happy to find many people like you
impressed and intrigued by these new concepts such as SoC, AOP, design
patterns and all other modern software engineering paradigms.

But deep in my heart, using XSP as a way to turn an OOP language into an
AOP one, it's a hack: sure, it can be done, but it might include hidden
mistakes that are not visible at first. One is the XML markup syntax
which is totally code unfriendly. Another is the intrinsic complexity of
the XML model: maybe there is a simpler syntax to add these concepts.

Anyway, whatever happens it's good and healthy to discuss these things.

> > >  Aspects of
> > > server processing can be abstracted by tags, and modularised by
> namespace
> > > prefixing.
> >
> > Yes, but I believe that it would be *much* better to avoid using the XML
> > syntax for that if all you want is code generation.
> I agree; server-side presentation processing is my sole concern here.

Ah, ok. I was talking more generally.
> > >  Even language and platform choice are aspects unders XSP's remit
> > > (witness AxKit).  Surely too useful for just pages (which are becoming
> an
> > > outmoded concept anyway).  Besides, being eXtensible conflicts with
> being
> > > restricted to page serving...
> >
> > Well, eXtensible doesn't mean "must do everything and brew coffee"
> Sure...thanks for trying to set me straight.  While being fully aware of the
> dangers of FS, I also think you have to recognise the futility of not
> following ideas through to full utility.  And XSP + logicsheets strike me as
> a very worthy combo for further development.

Oh, totally.

My role in this project has always been that of fueling innovation by
vaporizing random thoughts in the air and ignite it. Sort of mental
napalm, if you wish :)

But at the same time, balance this role with FS devil's advocate since
it's incredibly easy to get burned out by the powerful sensation of
intellectual creationism, which, in turn, becomes ego denfense,
code-less pride and, ultimately, negative social energy.

Careful: I'm not saying this is your case, not even close. Just wanted
to outline the path I try to follow and when I smell FS, I have to say
so.... then you are forced to go back and rethink about how much of FS
there is in your reasoning and you "clean it up", by removing everything
but the core.

Normally, it's in the core that the ideas reside.

And the process of removing FS from a intellectual creation, it's both a
difficul and a very stimulating one.

The fact that so many people use these design metodologies themselves
because they learned them from me makes me even more proud than all my
other technological achievements.

So, yes, I completely recognize the "futility of not following ideas
through to full utility". Absolutely, it's my creed! But every change
increases geometrically the number of variables it influences, so every
step forward must be carefully elaborated.

You might wonder: how can this work, then? well, just like debugging,
design decomposition and FS debugging is parallelizable and we are more
and more every day.

> > > IMHO, XSP's scope should be broadened to include server processes
> > (sitemaps,
> > > actions, ...), and XML fragment generation.
> >
> > As for XML fragment generation, this will be already in place once
> 'content
> > aggregation' is implemented.
> >
> > As for sitemaps and actions, I completely disagree: if you mean that java
> > falls short since it's not really aspect oriented, well, I totally agree
> > with you, but if you believe that using the XML syntax to add aspects to
> > java, well, I believe this is big time FS.
> See opening statements...I'm not trying to use XML to add aspects to
> anything - I'm merely noting the facility of XSP + logicsheets to delineate
> aspects within an XML server system...what I'm wondering is, can this power
> can be successfully and appropriately utilised elsewhere (ie other than just
> page generation)?

Good question.
> > >  I truly believe this would be
> > > powerful beyond belief (esp with recursive sitemap calling, and
> > sub-pipeline
> > > includes)
> >
> > recursive sitemap calling? are you kidding? Please, this is *exactly* the
> > reasoning path that leads to flexibility syndrome: if 'a' and 'b' are
> great,
> > extending to 'z' will make it better. This is, generally, wrong since it
> > doesn't take into consideration the 'costs' of such an approach. Cost in
> > both learning, using and, even more important, maintaining.
> OK - that was the 5am clarity statement.  Forgive my hyperbole, but please
> don't dismiss me out of hand.

:) ok

> I was thinking here of XSP's potential as a
> general purpose factory for server components other than
> would be a
> natural for this as it has already started to prove itself as an integration
> technology;  it would make my life simpler for one to have that flexibility
> in component construction available from sitemap calls other than
> map:generate.

Ah, now I get you: yes, Ricardo and I have been talking about this
extensively, on how to use the concepts of XSP to generate other parts
of Cocoon rather than generators.

Of course, transformers come to mind 
> Decreasing learning costs and improving maintenance is my middle name!

Great to hear that :)

> And also _would_ be a potential benefit of expanding XSP's remit. 
> Decreased learning cost - you just have
> to learn XSP.  Decreased maintanence - XSP markup has demonstrated it's
> utility in separating concerns, and capturing aspects.

You'll be happy to hear that this is exactly what we discussed: how to
make XSP 1.1 more general (one thing is to allow to avoid the use of the
xsp: namespace entirely) and separate the code generation from the
aspect aggregation semantics.

But we decided to wait until the Cocoon2 core design stabilizes before
sparkling yet another design quest. Hope you agree with me that too many
design irons in the fire could dissipate all the creativity energy and
kill the fire.
> > And, last but not least, understanding the impact over SoC and the cost
> > metrics of a web publishing framework: making a sitemap programmable
> > directly is not only dangerous, is WRONG.
> >
> > I repeat: WRONG!
> Again I agree:  *WRONG!*.  So here's where you'd start to think of improving
> XSP instead, precisely to address your concerns.  And if we agree that the
> language independance of XSP pages has to an extent encapsulated the "choice
> of implementation language" aspect, then _any_ language specific programming
> constructs in XSP are WRONG, since they break this encapsulation!

> Following this line of reasoning, the first thing you'd add to XSP would be
> the option to insist on only pure markup in an XSP page, no recourse to the
> underlying programming language.  This is definitely a direction I'd like to
> see for XSP, since it would encourage good style and portability, as well as
> the development of more powerful, flexible, and self-contained logicsheets.

Great! This is *exactly* why we want the xsp: namespace out of the way!
You should be able to write things like

  <para>Today is <date:today/></para>

and forget it!

This allows you to go to document writers and say "look, if you want the
date, use this tag and it will magically appear". This more or less the
same concept of word processor "fields" and writers love them!

Forcing them to encapsulate the page into

   <para>Today is <date:today/></para>

is not different from something like

  <para>Today is <date:today/></para>

which is totally bad!!! (as 10 years of HyTime limbo clearly showed!)

> An XSP sitemap would be a sterling example to future logicsheet authors,
> precisely because programmability would be disabled, and the logicsheet
> represent all possible configurations of a self-contained  and powerful XML
> server component.

Oh, I get you now. Yeah, in fact, this is already in place, more or
less. The sitemap compilation uses the same machinery XSP uses (Ricardo
wanted to refactor it out even more because there is some overlap left)
and yes, the sitemap markup can be seen as, more or less, taglibs.

Now that I think about it, the use of aspects in the sitemap (actions?
security?) could be associated to a different namespace.... hmmm I
wonder where this would lead... good reasoning though...

Anyway, the ultimate goal for XSP is to be so thin it becomes
transparent :)
> An additional restriction to consider would be to allow a logicsheet to
> declare itself uncompatible with anything but "friend" logicsheets, or at
> least to declare that they can only be used in certain restricted contexts.
> This
> could ensure markup mixing only occured up to the point anticipated by the
> logicsheet authors (if this were appropriate).  For example a sitemap
> logicsheet could declare that the flowmap logicsheet was the only other
> permissable markup in such hypothetical XSP components.  This again would
> help enforce separation.

Agreed. This is where the SiLLy language comes in, but Ricardo should be
the one to talk more about this.
> > because who administers the sitemap (the usability engineer, you might
> want
> > to call it) is almost never a programmer (programmers, by definition, have
> a
> > distorted view of usability anyway) and publishing systems have a very
> well
> > defined set of aspects, components and behaviors that must not be left to
> > everyone to rediscover or reinvent.
> Again I say make it a feature of XSP to allow disabling of programming
> constructs, and even allow disabling other logicsheets (ie, allow to specify
> that a logicsheet can only be used standalone).  This I believe would
> benefit XSP;  in general I believe expanding the remit of XSP would lead to
> a synergy between the development of XSP with the development of integrated
> technology solutions within it.  With appropriate refinements in place, I
> don't see the obstacle to having an XSP sitemap, rather I see the benefit.

Now that I understand you, I totally agree.

> > This is what a framework is: experience distilled into practices.
> I know this.  Experience can also be distilled into combinations of markup
> constructs.  This is the driving force for the creation of XSP
> logicsheets...but so long as XSP is restricted to pages, and not more
> general XML server processes, I'm not convinced how strong this driving
> force will be.
> Besides, some logicsheet tags already sit very uncomfortably between
> xsp:page tags, IMO, and this alone should be enough to start forcing a new
> development in the language.  A large proportion of the ldap, esql, and
> sendmail tags should really belong in a new XSP construct for marking up XML
> server processes.  What does sending an email or updating a database have to
> do with generating a page?  And as for the SOAP taglib....
> I think this alone is worth some attention...

Yes, yes, I agree!!
> > >, and it could be done without breaking the current XSP.  In a
> > > stroke, XSP's profile would be boosted, and C2 would be less proprietary
> > > (becoming a framework for XSP publishing components).  C2's codebase
> would
> > > also presumably shrink and be rationalised.
> >
> > proprietary? rationalized? are we talking about the same Cocoon?
> I'm terribly sorry!  Proprietary could hardly be a worse word to use for one
> of the most open of open source projects.  But still, saying "cocoon has
> an XSP language for integrating technologies with markup constructs, but
> only within "pages", whatever they are, and it also has a sitemap" sounds
> more proprietary to me than "cocoon is a platform for integrating
> XML server technologies using XSP, an extensible XML server processing
> language"

Bad terminology but good point. In fact, now that I understand you, I
can tell you that many core developers feel exactly the same as you on
this and, unfortunately, Ricardo's lack of time (and intrinsic
complexity of the matter!) has been deprimental to the whole cause.

But I'm sure things will change as Cocoon2 stabilizes and rough edges
will be smoothed.
> I used the term rationalised because at the moment the sitemap and XSP pages
> need to be pre-compiled, cached, re-compiled, aggregated, etc in two similar
> but different ways.  If another technology, eg a flowmap were to be added
> that operated in a third "the same but different" way, would this not be an
> indicator that a unification should be sought?  Such a unification would
> presumably rationalise parts of the codebase.

Have you talked with Ricardo lately? :) Gosh, these are more or less the
same words he's been using. I'm positive that if you give him a hand,
he'll be pleased to show you his intentions for this 'rationalization'.
> XSP's current an future structure is (and should be) an open invitation to
> extension, integration, and continued development.  I need convinced
> the same can be said as easily of the sitemap.

Agreed, even if solidity of contracts (that is markup, interfaces and
the like) is a great value and back incompatibility must be sacrificed
for the sake of 'elegance' only when it's valuable to do so. (like we
did with Cocoon2)
> > > (conclusion reached after following Uli's application rant on
> > cocoon-users,
> > > and developing my own C2 web-app, writing action after action to do the
> > same
> > > thing for different forms, longing for XSP actions, feeling locked in by
> > > proprietary sitemap.  Just the usual $0.02 worth in other words).
> >
> > I don't follow cocoon-users and I believe that placing a rant on
> > cocoon-users is totally meaningless.
> When Uli used the term rant, it was only in humility I'm sure.  The thread
> he started should have been entitiled "a timely expose and invitation
> to discussion of cocoon in web-apps".  Several other threads on
> cocoon-users have gone this way recently too...
> > Cocoon was not designed with webapps in mind, admittely, not even Cocoon2
> so
> > far and the 'action proposal' is not enough thought out to represent a
> clear
> > design (even Giacomo agrees with me on this).
> >
> > Admittedly, this is a problem, but moving XSP to cover everything results
> in
> > costs many will not be able to afford.
> I hope I'm not being dim-witted, but I still don't quite understand what
> these costs might be...  Unification of concept isn't a cost.  The sitemap
> could probably
> already be hacked into an XSP page (using inner classes perhaps?) as it
> stands (not that I'd recommend this).  Some simple refinements to XSP could
> make for the simple, powerful and flexible configuration of a myriad cocoon
> components, as well as broadening XSP's scope.  I'm afraid I am still in
> need of further enlightenment as to why this is not appropriate...

No, forget this, it was based on my wrong understanding of what you mean
by "refactoring and integration". Now I'm confident I agree with you on
almost anything you've been saying.
> > Do you want a design that brings Cocoon's publishing elegance to include
> the
> > functionality required by web applications? I do. I feel this is the only
> > thing that might impact the Cocoon API and thus, the only thing that stops
> > us for entering 'beta' state.
> >
> > How do we do that? are actions and HTTP action handlers enough? how
> reusable
> > can be make actions? how granular the MVC patterns can be applied to the
> > generation stage? how much overlap there is between existing solutions
> like
> > Turbine or Struts, how much can we reuse of their models?
> >
> > Making the sitemap directly programmable is nothing different from writing
> a
> > big servlet that uses Cocoon components as it wishes. Result: 'subversion
> of
> > control'. Another big anti-pattern.
> Just to reiterate, I don't recommend this.  I do wonder though of the
> potential in new XSP constructs (some being explicitly unprogrammable
> except through logicsheet markup), and consequently of XSP's suitability
> across the board as the language of XML servers.

Sorry, this was the contextual mistake that stirred the discussion in
the wrong direction. Glad to find the context reestablished.
> > > (and thanks to Paul Russel for the interesting reply to similar email on
> > > cocoon users...hope for the same, to shut me up once and for all about
> > > xsp sitemaps, or otherwise:)
> >
> > Cocoon was designed with the idea that POST actions were handled by
> > something else. This has never been stated, but after careful thinking I
> > believe there is a specific asymmetry in how the system was designed.
> > Result: in Cocoon, GET is natural, POST is ackward.
> >
> > This is what generates friction and ranting.
> >
> > But I reanalized the architecture and found no evidence of this asymmetry
> in
> > the design, it's just a consequence of lack of focus on web applications.
> > Cocoon maps the IoC model of servlets and, just like servlets, it's
> totally
> > agnostic on how you build your web application, unlike frameworks like
> > Turbine or Struts that create patterns internally at the generation stage.
> >
> > Cocoon personalization is based on generators: just like pure servlet
> > programming is hard and expensive, pure generator programming by code is
> > hard and expensive. So, what do we do?
> >
> > Following the JSP patterns, we created the Cocoon equivalent of JSP model
> 1
> > with XSP, but we stopped there:  XSP were not designed with model 2 in
> mind,
> > thus MVC is not implemented in its design, but it's left to the ability of
> > the XSP author.
> >
> > There are a few questions that we need to answer:
> >
> >  1) how do we implement MVC in generators? (extend/modify XSP or use
> things
> > like Velocity/WebMacro)
> >  2) are actions general enough to belong to the sitemap?
> >  3) sitemaps are declarative pattern matching based on request and there
> is
> > no notion of flow, which is left implicit inside the web application. Is
> > there a way to identify a "flowmap"? Is this information useful? can this
> > enforce the use of top/down design on web applications, working along with
> > the usability engineer?
> >
> > making the sitemap more programmable is not an advancement, it's a hack.
> Just to reiterate, this was not what I was proposing.


> > what we need is more thinking not rants.
> I'm thinking - I'm thinking!!  I'm also an experienced developer with some
> time on my hands (became a student again..ahhhh relief!)...I'd like to be
> able to find common ground here, and hopefully muck in...

That's great.

Ricardo, if you find the time, this call is for you :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message