[RT] Cocoon as OS

[Greg Weinger]

One of the most intriguing and provocative comparisons I've heard about Cocoon is to Unix, in that it provides a host of small generic components that can be piped together to create new output.  Cocoon is like an operating system for web resources.    This analogy got me started on a line of thinking about the direction Cocoon is taking.  The more I think about it, the more satisfying I find the Unix analogy both as a description, and as a potential guide for future development.    On top of the work being done on the interpreted sitemap, and the Scheme flow scripting, I propose a Cocoon shell, and to officially sanction the operating system analogy, to further the conceptual cohesion and utility of this growing number of technologies.    How is Cocoon like an Operating System?   “Operating System Concepts” by Silberschatz and Galvin, identifies three main aspects of a traditional Operating System: * Process Management * Storage Management * Protection and Security   Process Management ------------------- HTTP requests are akin to OS processes, managed by the cocoon sitemap engine.   Storage Management ------------------- I don’t think that enough has been made of the fact that the sitemap manages URIs to resources in the same sense that a filesystem manages names and paths to files (for a good explanation of this, see Stefano’s thesis).  We could even conceieve of the sitemap as a URI-System.   What really distinguishes the sitemap from the filesystem (apart from low-level resource management) is that the abstraction also expresses the seperation of concerns between content, logic, and presentation.    Whereas with a normal filesystem directory listing (ls) you get:   /news.xml   A Cocoon shell directory listing might give:   /news.xml -        G – http – http://newsfeed.org/feed.html -        T – NewsTransformer -        T – xslt - local.xsl -        S - XmlSerializer   Look familiar?  A command line would allow you to manipulate the URI-System in real time, if you have the correct permissions, of course.    Protection and Security ----------------------- Cocoon’s responsibility here is to provide a useful abstraction that hooks into to any number of supporting hardware and software.  This security abstraction would mimic UNIX-style users, groups and permissions, with hooks to filesystem security, CMS, LDAP, etc.   A directory listing would give:   /build.xml                            Intranet       drwxr-xr-x -        G – file - feed.xml          Dev1           -rw-r—r-- -        T – NewsTransformer          Dev2           -rw-r—r-- -        T – xslt - local.xsl         Dev2           -rw-r—r-- -        S – xml                      Administrator  -rw-r—r--   Voila! Cocoon can now expresses and manage both the inward and outward flow of information.      Shell Scripts -------------- Finally, the flow scripting Ovidiu is working on could be considered shell scripts.  They can be executed by an external HTTP request, from the Cocoon shell (with parameters), a CocoonChronTab, or the CLI.     Cocoon shell scripts could express an entire pipeline.  A questionnaire web application could be expressed in this way:   /questionnaire                 -        S – webQuestionnaire.cscript       Shell   The shell would be directed primarily at the administrator and advanced user, but could serve as the basis of any number of user applications.  The best thing about this is that it maximises utility to the power user.  And what environment could be more familiar to the average web administrator?    Useful commands would be lists of each type of component (list all serializers, list all generators) the ability to add and remove components, the ability to create and manipulate piplelines, set permissions, etc.   The current sitemap could be exported to maintain state, or it could be used as an alternative method of manipulating Cocoon.  But I wouldn’t be too attached to the XML sitemap; it’s the abstractions that are the key, not the markup.      Semantic Searches   This is an aside, but it would be interesting to attach some semantic search capabilities to a pipeline, so that meta-information could be extracted not only at a Site level, but at a URI level.  This could support the meta-information functionality in WEBDav.  The component would return a set of properties stored a static file, a database search, or the results of an automatic indexing analysis engine on that URI.      <map:match pattern=”topic” meta=”properties.xml”>    <map:generator/>    <map:transformer />    <map:serializer /> </map:match>