Brian Topping wrote: > > [sorry if this has been discussed before...] > > I've put some thought into something similar in the CMS space, but > didn't really realize that it might have been on the same path as the > "Cocoon as OS" thread until just a few minutes ago. A Cocoon > underlayment of sorts, but as a CMS. Let me explain. > > Cocoon solves a very specific class of problems. I see it as a general > processing unit for information that is recalled from external storage. > Once normalized to a SAX stream by a generator, the GPU has it's way > with the data. This Generator normalization is no different than the > normalization of data coming in from a tape drive to a processor > backplane. Once processed, the data is sent out a Serializer, analogous > to taking it from the backplane and sending it to an output device such > as a printer. > > But if this is true, is Cocoon an 8-way SMP machine without an operating > system?
This is a very good question: Cocoon is more similar to an operating system or to the underlying hardware? > I don't want to get too tied up in the analogy, but reapply the three > things that Greg brings up about the OS: Process Management, Storage > Management and Protection/Security. Yep. > * Process Management: Well handled by Cocoon itself. It is able to > handle HTTP requests with lightning speed, thanks to the sitemap engine. > This could be supplemented with a graphical ability in the CMS for > individual users to modify and manipulate pipelines and other relevant > details of the process as well. Storage and version control of Cocoon > configuration can also be managed as a part of the CMS. Oh, absolutely. This is a totally different concern and can nicely sit on top. > * Storage Management: If you are happy with basic disk drive storage, > Cocoon is fine. But there is little in the way of middleware analogous > to something like Veritas Volume Manager that can handle transparent > versioning and volume control. Clearly this belongs in the CMS and not > in Cocoon, but traditional CMS implementations always seem to hack the > functionality for staging, usually requiring separate installations for > each staging system. This is an administrative burden to keep > operational, and something that a transparent underlayment could handle > with ease. Integrated with Cocoon as a special Generator, the system > would be really very slick. Exposing the CMS to Web Services or through > EJB would be like putting the storage on a SAN, accessible throughout > the enterprise. Here you are beginning to touch the very nerve: what Cocoon is missing today (yes, I'm holding off a big RT due to the 2.0.1 release, I'll fire soon) is the ability to 'componentize' its web applications. 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. Note: I've looked around for *every* web technology in existance and there is nothing like that, not even EJB (which are close, but work in a totally different direction). I want avalon-like componentized cocoon web applications! I want polymorphic behavior of webapp modules! I want behavioral-discovery of webapp modules! 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 componets so that you can deploy several things on the same Cocoon. Avalon is a component framework and Cocoon is an avalon application. I want Cocoon to look as Avalon (not at a huge monolithic servlet, damn it!) for any webapps. This is also the reason why I don't like the OS parallel: UNIX is both an OS and a development framework. But the 'framework aspects' cross-cut the entire OS. For example, the 'pipeline' concept is a crosscutting aspect in UNIX: you need a bunch of things to make it work: - the 'everything is a stream' paradigm - the 'STDIN/STDOUT' concepts - a shell/script to glue pipeline components together I like to think at Cocoon as a 'framework'. Period. Every OS *must* give some operative constraints, but very few OSes were designed with SoC in mind! (microkernel design probably goes in this direction and the fact that Linux prefers concern monolithicity compared to nice separation strikes me as an evolutionary suicide, but that's my personal opinion an outsider so it doesn't count) > * Protection/Security: This ties into the users and workflow aspects of > a traditional CMS. In the analogy of a processor, a processor > initializes into supervisor mode, loads the kernel, and starts user > processes. A CMS working with Cocoon could supplement this paradigm, > with Cocoon as the supervisor / Controller pattern and the CMS as the > Model. Here you are talking about 'installing the webapp module', much like you would do in in Avalon/Phoenix. > I see a few things missing though, predominantly what would be > considered in the application/user space, and mostly in the area of > content editing and manipulation. 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. > What I am wondering is whether such a CMS has any business being that > tight with Cocoon. If not, a set of interfaces ought to be developed > for them to couple through, but either way is this an attractive vision? 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. I mean: we have actions, right? access control is an action, no? Cool, we have the ability to add access control in Cocoon. The only thing that we miss right now is the ability to let *you* deploy your ACL-action in a nice and easy way and creating such strong contracts between webapp modules, that you can think of 'reusing' them on different things. see my next RT on this for more details. > There is a CMS group that has recently formed > (http://groups.yahoo.com/contentmanagementgroup), but I am not sure that > the goals of this group are going to be so tightly wed to Cocoon when it > the dust clears. That's not commentary on their goals, but the converse > is that I think Cocoon *deserves* this kind of integration and am > interested in how to facilitate that. Absolutely. > 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 want control back, damn it! It should be Cocoon to deploy your things, not *you* placing things around in Cocoon. It's its concern, not yours! > Comments? I see this as a completely parallel development to Cocoon, > but one that might really make it accessible to the masses. And it > would be a blast to work on! 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 :) It won't happen tomorrow, but it won't take long (gosh, bugs are opened and closed in *hours*! not even Microsoft can do that!) And with the help of everybody, it will happen even faster! -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
