> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > 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 started. 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! :B --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
