cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <>
Subject RE: [RT] Cocoon as OS
Date Sat, 02 Feb 2002 14:04:51 GMT
> From: Stefano Mazzocchi [] 
> I mean: if part of a CMS is built as cocoon webapp (and I think we all
> see why this would be a benefit, both on the frontend and on the
> backend), it should be possible for this webapp not only to 
> specify its
> sitemap and what cocoon components to use, but also to 
> 'deploy' its own.
> <snip/>
> I want avalon-like componentized cocoon web applications!
> I want polymorphic behavior of webapp modules!
> I want behavioral-discovery of webapp modules!

Yes, I am seeking vision as much as trying to provide it, but this
matches my mental noise precisely.  The CMS (or other management-like
applications) are "setuid" software, in essence.  

I would prefer to stay outside the boundaries of Cocoon, but the ability
to intermingle with it through polymorphic behavior is an angle that I
hadn't even considered.  Very clever, very clean.

> When we have this, it would be piece of cake (really!) to provide all
> kind of personalization thru the ability to deploy not only sitemap
> components, but also general components so that you can deploy several
> things on the same Cocoon.

Yes, and through polymorphic registration of their callbacks, the power
that developers of these components would have at their disposal would
be immense.

> > ...But by exposing APIs that are modal
> > to ACL context, very powerful interfaces could be built in a secure
> > manner.
> I'm not sure that access control belongs to Cocoon's concern realms.

Possibly not.  But a vision that is becoming clearer is one of
registration of authentication components that are "privileged mode" as
it were.  The "setuid problem" exists in a content environment when
considered from the standpoint of staging and access control.  I presume
that the webapp component interfaces would be monolithic, so it would be
relatively easy for a rouge webapp to impersonate an authentication
controller since they both have access to the same client interfaces.
While I don't believe that the nuts and bolts of ACL belong inside
Cocoon, the "supervisor mode" paradigm that supports OS processes does,
IMO.  This mirrors the paradigm of the supervisor/user modes of the
processor and privledged/unprivledged modes of the OS.  In the end, all
we are looking to solve is the priv/unpriv problem for webapps.

> I have the perception that Cocoon might provide components for access
> control, but should not have this semantics built right into its main
> concepts (see sitemap, flowmap).
> Or maybe not: access control is a first-class citizen of the realm of
> publishing (both on the front and on the back).... but I have the fear
> that tighting this too much might blow Cocoon into a full CMS 
> and I want
> to keep this decoupled: Cocoon is already big enough.

Yes, I agree completely.  Does the concept of priv/unpriv address these
concerns?  Cocoon would install out of the box with a dummy
authentication manager implementation that always answers "root",
through Avalon (or Cocoonalon) configuration, a different authentication
manager could be blessed for polymorphic registration on startup and
answer a little more discriminately ;)  

> I mean: we have actions, right? access control is an action, no? Cool,
> we have the ability to add access control in Cocoon.

These access control actions could be stubs to the installed
authentication webapp.

> > The power of Cocoon deserves a
> > compliment that exposes it full strength, in a manner that 
> allows both
> > "superuser access", "user access", workflow management, integrated
> > staging, ACL and access management, etc.  It's not much different at
> > this level than what I consider Greg might have been 
> seeing, but just
> > expressed differently.
> The wyona guys managed to add exactly these features providing
> components to extend the cocoon functionality (but didn't touch the
> engine!), the only bad thing is that they have to ship a 'composed'
> cocoon. So, basically, today you are forced to 'extend' Cocoon.

I'm really juiced about Wyona.  I think they hit the nail on the head
with their grammars for workflow management.  The only twist that keeps
coming back to me is whether WSFL would be the more correct way to
orchestrate.  They might have used this had it been around when they

I'm thinking the bigger picture of how this fits into the enterprise
that is entirely scripted by WSFL.  Cocoon could conceivably be used as
a giant terminal server for web clients that want access to "behind the
firewall" Web Services, and a seamless publishing repository for
enterprise systems that want to publish XML data through Web Services to
Cocoon.  Exposing the Wyona interfaces to Web Services enables that
access, scripting it with WSFL integrates it with business process
modelers that are already producing the show.  It's pretty compelling...
> Here is the future I see:
>  - take Cocoon today
>  - polish it
>  - add continuation-based flowmaps 
>  - add polymorphic behavioral-based webapp componentization
> Voila': the perfect framework to build your CMS (and your e-commerce
> site, your groupware intranet, your e-learning solution...) upon :)

Well, +1 from here.  I'd rather build this one right than build it
twice.  I would be honored to help.  I'm not nearly as adept with Cocoon
as I would like to be, but I am a very quick study and don't hide my
limitations.  This kind of project would help me get the experience with
Cocoon that I am looking for.  So if there is something that I could do
to help move this forward, please don't hesitate to ask!


To unsubscribe, e-mail:
For additional commands, email:

View raw message