Stefano,
I can't profess to understand all you've said here, me being more of a
user of Cocoon than one of its developers. I do like the idea of the
distributed future you talk of.
If you are hinting at Cocoon3 being refactored hugely from Cocoon2, then
perhaps a useful excercise would be survey the current users as to what
they use, what they would like and what they dislike. It might also be
cool to survey people who use (or developed) competing technologies, as
some of their input may be valid opinion (as opposed to bogus prejudice).
Regards,
- Paul H
>Cocoon is currently a publishing framework, meaning that is somewhat
>more powerful for stateless resources than for stateful ones.
>
>I strongly believe that Ovidiu's work on Schecoon will (sooner or later)
>bring balance to this picture, allowing Cocoon to be as powerful with
>stateful resources than it is today with stateless ones.
>
>This considered, the concept of 'cocoon application' is to be extended
>to include all possible sums of stateful and stateless resource serving.
>
>These RT are based on the assumption that the above is true and try to
>address the future needs for cocoon application design, programming,
>debugging, refactoring, maintenance, installation and deployment.
>
> - o -
>
>Cocoon has been described as a 'framework', a 'pipeline engine' and even
>as a 'web operating system'. While one can disagree with these
>metaphors, one thing is common between these descriptions: cocoon runs
>your applications.
>
>Well, to be honest, today Cocoon runs 'one' application, or, in some
>circumstances, a disorganic collection of independent applications
>sharing the same URI space.
>
>This reminds me of the trend that appeared on software system: the first
>systems were monolithic monotasking environments, then started to appear
>multitasking environments, preemptive multitasking (IoC anyone?) and
>more recently, component based environments and distributed component
>based environments.
>
>In order to grow architecturally, I strongly believe that cocoon must
>allow (not force, allow!) the componentization of the applications it is
>capable of running.
>
>Why this? in order to allow easier reuse of modules, both in different
>applications running at the same time, both in different applications
>developped in different times.
>
>I also believe that Cocoon should wait to enter the 'distributed' realm
>until this componentization effort is finished. Doing it *before* might
>be extremely dangerous (this is the same pattern we followed for Avalon:
>get strong locally first, then think of growning distributed)
>
> - o -
>
>Cocoon is an avalon application and avalon applications are
>componentized and avalon forced you to design your applications thinking
>about the components that make it up.
>
>I would like to do the same with Cocoon applications, just at another
>level: Avalon concentrate on modularizing the programming logic, Cocoon
>must induce cocoon application designers (I can't talk of programmers
>since it should not be a programmer to design a cocoon application but
>an entire team sharing different concerns) to modularize their stuff.
>
>But how is a component model for cocoon applications useful?
>
>1) components can be defined behaviorally: in Avalon, if you need a
>Store, a Logger, a ThreadManager, a Clock, etc... you just ask for a
>component that performs that 'role'. Avalon takes care of everything
>else, just hands you the component that you need to do your job. In
>short, it reduce concern overlapping between the composer (who uses the
>component) and the component.
>
>I would like the same to happen in Cocoon: a webmail written as a cocoon
>application will require user authentication and authorization, mail
>transport facilities (both to IMAP and to SMTP), skins, a persistent
>repository for user preferences, a persistent repository for addresses
>or a connection to the addressbook storage (LDAP, for example), a
>connection facility with the server side filter engine (Sieve, for
>example), etc...
>
>Being a programmer (like it or not), the 'axis' I use to componentize a
>web application is normally the functionality (the logic concern realm).
>My personal experience tells me that this is almost never the case for
>other types of individuals: graphic designers will divide components
>depending on graphical attributes, wording editors will divide
>components depending on verbosity and other word attributes
>(informative, activity, indications), usability engineers will divide
>components depending of the complexity of their flow.
>
>The question is: since these diffenent componentizations *always*
>cross-cut, can Cocoon make it possible to have all these coexhist?
>
>I believe so.
>
>The only price to pay is an increased number of contracts between the
>different realms and a consequent higher frequency of redesign and
>refactor (which might also turn out to be healthy)
>
>Let's make an example: suppose you have three concern realms A,B,C each
>with a different 'component' view of the problem and some overlap.
>
> A [ | | | ]
> B [ | | | ]
> C [ | | | | ]
>
>the idea is to have a higher granularity of componentization
>
> [ | | | | | | | | ]
>
>and then somewhat glue togheter the components in the same realm
>
> A [ * * * | | * * | ]
> B [ | * | * * * | * ]
> C [ * | * | * | | * ]
>
>An example of such a 'glue' is content aggregation: things that were
>componentized at the 'logic' level are glued back together at 'content'
>level.
>
>The drawback is that we have a higher number of 'marks' in the picture
>(both '*' and '|') and each one of them is a contract, so eventually
>requiring changes and possibly impacting more than one concern island.
>
> - o -
>
>Now that we have identified the theory, let's try to dive into the
>practice.
>
>Suppose we have a simple web site and we want to make it skinnable.
>
>We decide to have a higher order modularization separating 'content'
>from 'style' and using the markup schema and the location of the
>sytlesheets as a contract between the two components.
>
>The flow of composition is that 'content' requires a 'skin' in order to
>be functional.
>
>So, we have component 'MysiteContent' that implements 'Content' and
>requires an instance of the component 'Skin'.
>
>We deploy 'MysiteContent' on top of Cocoon, indicating where we want to
>mount it (let's say '/' which is the root of the addressing space
>handled by Cocoon).
>
>The deployment descriptor of 'MysiteContent' will indicate that it
>requires an instance of 'Skin' in order to operate. Cocoon will prompt
>for a list of components that implement the 'skin' role and allow you to
>choose between them.
>
>if none is present, you will be asked to provide one.
>
>Of course, this is just an example of functionality: it could be
>entirely possible to deploy an entire application with all the required
>components inside, but this is just implementation details.
>
>But what does it mean, in practice, that the 'CoolSkin' component
>implements the 'Skin' role?
>
>Let me make a sitemap example to see what I envision:
>
> <match pattern="*.html>
> <generate src="docs/{1}.docbook"/>
> <transform src="[skin]://docbook/docbook2html.xslt"/>
> <serialize/>
> </match>
>
>where the absence of 'protocol' information indicates that the component
>should look into its internal addressing space, while the [***]: virtual
>protocol indicates that you should connect to the implementation of the
>'skin' role that you have choose at deployment time.
>
>So, what is the contract here? the location of the stylesheet in the
>internal addressing space of the 'skin'-implementing component.
>
>The above gives us:
>
> 1) complete separation: components are totally independent as long as
>their contracts are not touched
> 2) polymorphism: I can have multiple implementations of the same role
>and decide (even at runtime!) what to choose.
> 3) total reuse across different apps: I could use the same module for
>different installations and webapps (think of
>authentication/authorization module
>
>Last but not least, these components must have the ability to install
>new java components into cocoon without having to modify the cocoon
>installation.
>
>if a webapp requires a special hand-written transformer, this should be
>installed along with the deployment descriptor and might even be little
>as having one cocoon app component as one cocoon component.
>
>Ok, enough for now.
>
>Awaiting for your comments!
>
>Ciao
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
