You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Greg Weinger <gw...@itmedicine.net> on 2002/01/29 04:00:13 UTC
[RT] Cocoon as OS
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>
Re: [RT] Cocoon as OS
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
> I agree with you, but only one thing: httpd.conf seems to suggest
> one2one URI2filesystem matching and only a module provides rewriting
Well it's hard to call mod_alias a module - I can't imagine many serious
Apache server being compiled without it. You're thinking of mod_rewrite,
which is just scary ;-)
Of course mod_alias only maps directories, but then Apache doesn't have
any concept in http_core of dynamic generation, so it doesn't need
anything more.
--
<!-- Matt -->
<:->Get a smart net</:->
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon as OS
Posted by Stefano Mazzocchi <st...@apache.org>.
Matt Sergeant wrote:
>
> On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
>
> > Matt Sergeant wrote:
> > >
> > > On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
> > >
> > > > > 3) The analogy of the sitemap to a filesystem ("the sitemap is like a
> > > > > specialized filesystem for URIs") could be a very powerful explanation
> > > > > to first-time and beginner cocoon users. Maybe I should have said,
> > > > > "Sitemap as Filesystem" instead of "Cocoon as OS". This may be
> > > > > something to put in the documentation.
> > > >
> > > > I'm not sure this is the way I like users to see the sitemap. In fact,
> > > > it was created *exactly* to show that one2one URI-space filesystem space
> > > > is a hack from the NCSA days and should be avoided, even in your mind!
> > >
> > > If you really felt strongly about that the sitemap/matcher would have no
> > > "wildcard" support
> >
> > I never said that!
>
> I know, I'm taking the argument to the extremes.
>
> The point is that Cocoon's wildcard system works in almost exactly the
> same as any web server's DocRoot system. So Cocoon is no "better" in this
> regard to any web server.
>
> Of course that's an oversimplification, not everyone uses something like:
>
> <map:match pattern="*">
> <map:generate src="root/{1}.xml">
> ...
> </map:match>
>
> But I would imagine that's the easiest thing to do at first, and suffers
> exactly from all the breakages possible with a direct URI->fs mapping that
> web servers use.
>
> That's all. It's not really a criticism - because if you made it more
> complex it would be a pain in the ass to use. There's always going to be
> compromise between those who want to be able to shoot themselves in the
> foot to get something done fast, and those who want to take longer but be
> assured of safety.
Ah, now I get your point.
I agree with you, but only one thing: httpd.conf seems to suggest
one2one URI2filesystem matching and only a module provides rewriting
rules (yeah, well, it also brews coffee, but that's Ralph's view of
software programming), the Cocoon sitemap is (in my humble and heavily
biased opinion) more balanced between the need for simple URI management
and normal URI2resource mapping capabilities.
I won't be surprised to see people adding sitemap-like semantics to
Apache 2.0 once pipelines of modules start appear.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon as OS
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
> Matt Sergeant wrote:
> >
> > On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
> >
> > > > 3) The analogy of the sitemap to a filesystem ("the sitemap is like a
> > > > specialized filesystem for URIs") could be a very powerful explanation
> > > > to first-time and beginner cocoon users. Maybe I should have said,
> > > > "Sitemap as Filesystem" instead of "Cocoon as OS". This may be
> > > > something to put in the documentation.
> > >
> > > I'm not sure this is the way I like users to see the sitemap. In fact,
> > > it was created *exactly* to show that one2one URI-space filesystem space
> > > is a hack from the NCSA days and should be avoided, even in your mind!
> >
> > If you really felt strongly about that the sitemap/matcher would have no
> > "wildcard" support
>
> I never said that!
I know, I'm taking the argument to the extremes.
The point is that Cocoon's wildcard system works in almost exactly the
same as any web server's DocRoot system. So Cocoon is no "better" in this
regard to any web server.
Of course that's an oversimplification, not everyone uses something like:
<map:match pattern="*">
<map:generate src="root/{1}.xml">
...
</map:match>
But I would imagine that's the easiest thing to do at first, and suffers
exactly from all the breakages possible with a direct URI->fs mapping that
web servers use.
That's all. It's not really a criticism - because if you made it more
complex it would be a pain in the ass to use. There's always going to be
compromise between those who want to be able to shoot themselves in the
foot to get something done fast, and those who want to take longer but be
assured of safety.
--
<!-- Matt -->
<:->Get a smart net</:->
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon as OS
Posted by Stefano Mazzocchi <st...@apache.org>.
Matt Sergeant wrote:
>
> On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
>
> > > 3) The analogy of the sitemap to a filesystem ("the sitemap is like a
> > > specialized filesystem for URIs") could be a very powerful explanation
> > > to first-time and beginner cocoon users. Maybe I should have said,
> > > "Sitemap as Filesystem" instead of "Cocoon as OS". This may be
> > > something to put in the documentation.
> >
> > I'm not sure this is the way I like users to see the sitemap. In fact,
> > it was created *exactly* to show that one2one URI-space filesystem space
> > is a hack from the NCSA days and should be avoided, even in your mind!
>
> If you really felt strongly about that the sitemap/matcher would have no
> "wildcard" support
I never said that!
> and you'd have to key in each and every new URI into
> the sitemap. Of course nobody would use the software then, but *shrug* ;-)
Absolutely!
Sorry, but I think I didn't get your point :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon as OS
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 30 Jan 2002, Stefano Mazzocchi wrote:
> > 3) The analogy of the sitemap to a filesystem ("the sitemap is like a
> > specialized filesystem for URIs") could be a very powerful explanation
> > to first-time and beginner cocoon users. Maybe I should have said,
> > "Sitemap as Filesystem" instead of "Cocoon as OS". This may be
> > something to put in the documentation.
>
> I'm not sure this is the way I like users to see the sitemap. In fact,
> it was created *exactly* to show that one2one URI-space filesystem space
> is a hack from the NCSA days and should be avoided, even in your mind!
If you really felt strongly about that the sitemap/matcher would have no
"wildcard" support, and you'd have to key in each and every new URI into
the sitemap. Of course nobody would use the software then, but *shrug* ;-)
--
<!-- Matt -->
<:->Get a smart net</:->
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon as OS
Posted by Stefano Mazzocchi <st...@apache.org>.
Greg Weinger wrote:
>
> > If I understood correctly, your stream of thought was something on the
> > line of:
> >
> > 1) Unix uses pipelines, Cocoon uses pipelines.
> >
> > 2) Unix has interactive shells to compose those pipelines (or the
> > ability to run scripts for those shells), why shouldn't cocoon have
> the
> > same concept?
>
> 3) The analogy of the sitemap to a filesystem ("the sitemap is like a
> specialized filesystem for URIs") could be a very powerful explanation
> to first-time and beginner cocoon users. Maybe I should have said,
> "Sitemap as Filesystem" instead of "Cocoon as OS". This may be
> something to put in the documentation.
I'm not sure this is the way I like users to see the sitemap. In fact,
it was created *exactly* to show that one2one URI-space filesystem space
is a hack from the NCSA days and should be avoided, even in your mind!
> 4) The presence of a shell would help solidify the analogy.
Exactly. That's why I don't see the need for it. I see the need for a
powerful and easy to use (even remotely, if you care) sitemap editing
tool, but shells are terminal emulators... I think we have much more
advanced technologies to use now :)
> 5) What other design cues can we take from this?
Going down this path is *very* dangerous. People will start thinking
about 'hey, what is the cocoon parallel of a device?" and then propose
something absurt just to keep the parallel going.
Sometimes parallels are good, but between IT and reallife... I find
intra-technology parallels too dangerous for the explaining help they
give us.
> > 1) I've heard talking about Cocoon as a 'XML pipeline engine'... now
> you
> > are proposing to call it an "web operating system"... the first is too
> > little, the second is too much.
>
> Agreed. It's an overstatement.
>
> > 2) an interactive shell isn't really different from what Ovidiu is
> > working on (even connecting Emacs directly to the scheme sitemap
> engine)
> > and I agree that it might be a good parallel to show that he might be
> > going in the right direction
>
> Exactly.
Don't get me wrong: the UNIX shell is an extremely powerful tool, but
it's an old technology. People is now using webapps or general
client/server architectures for things they used to do with remote
shells.
So, while I like the concept of being able to do extremely short
try/fail/retry sitemap editing cycles, I don't think that cloning a
shell will be of any use for this (see the JXTA shell for an example of
something useful on paper and virtually useless in practice)
Write me a sitemap XUL editor and you'll make me happy :)
> > 3) a shell *DOES* *NOT* solve the 'data inward' asymmetry that cocoon
> > appears to exhibit. It is a development tool. Possibly a way to author
> > the sitemap, but I see *MANY* better solutions.
>
> I was on the weakest ground regarding data flow assymetry. But what
> about integrated security? Like the filesystem, is that another concern
> island we could wrap into the sitemap? From an application developer's
> perspective, security seems like a mess to me (there are so many
> options). What if we could make that more seamless? Unless you think
> I'm way off base, I'd like to come up with a proposal for this.
I can't guarantee anything, but please do. I'd like to see what others
think about the concerns the sitemap should cover.
> Certainly we can and should come up with better administrative solutions
> than a shell, but its presence could be comforting to web developers and
> administrators, and increase adoption.
I won't be necessarely against the development of such a shell, but I'd
rather have people spend time on a more modern editing enviornment.
> Some of these thoughts started out from thinking about the question,
> "What is Cocoon?" which I do because I'm always trying to explain it to
> people. The website begins with "Apache Cocoon is an XML publishing
> framework that raises the usage of XML and XSLT technologies for server
> applications to a new level." The beginning of that sentence seems like
> it's becoming more and more of an understatement.
>
> Maybe we should say "Cocoon is a web publishing and applications
> framework that raises the usage of XML and XSLT technologies for server
> applications to a new level."
We'll get there, but for now we decided to keep a low profile in order
to avoid people coming in and say 'look XYZ is much better for webapps,
you are just cool at publishing'.
Now people are sayng 'gosh, cocoon has great potentials on the webapp
side as well'... yes, we'll get there, but it's a slow process, and once
you are dealing with so many strong concepts and design decisions, you
have to be *very* careful in make it a 'slow' growth... of forking
friction will develop and might split the community in two.
And I'd rather loose users than developers :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon as OS
Posted by Steven Noels <st...@outerthought.org>.
> -----Original Message-----
> From: Greg Weinger [mailto:gweinger@itmedicine.net]
> Sent: dinsdag 29 januari 2002 22:28
> To: cocoon-dev@xml.apache.org
> Subject: RE: [RT] Cocoon as OS
>
> Some of these thoughts started out from thinking about the question,
> "What is Cocoon?" which I do because I'm always trying to
> explain it to
> people. The website begins with "Apache Cocoon is an XML publishing
> framework that raises the usage of XML and XSLT technologies
> for server
> applications to a new level." The beginning of that sentence
> seems like
> it's becoming more and more of an understatement.
>
> Maybe we should say "Cocoon is a web publishing and applications
> framework that raises the usage of XML and XSLT technologies
> for server
> applications to a new level."
This has already been discussed (to some length):
http://marc.theaimsgroup.com/?t=100634560000002&r=1&w=2
and I vaguely remember the valid point/conclusion of someone (dunno who
anymore) that we should only start talking about an app framework when
the flowmap vision was fully implemented (cfr ScheCoon)
IMHO, people do find Cocoon a different beast than Struts, Webwork &
Expresso to name but a few
Regards,
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon as OS
Posted by Greg Weinger <gw...@itmedicine.net>.
> If I understood correctly, your stream of thought was something on the
> line of:
>
> 1) Unix uses pipelines, Cocoon uses pipelines.
>
> 2) Unix has interactive shells to compose those pipelines (or the
> ability to run scripts for those shells), why shouldn't cocoon have
the
> same concept?
3) The analogy of the sitemap to a filesystem ("the sitemap is like a
specialized filesystem for URIs") could be a very powerful explanation
to first-time and beginner cocoon users. Maybe I should have said,
"Sitemap as Filesystem" instead of "Cocoon as OS". This may be
something to put in the documentation.
4) The presence of a shell would help solidify the analogy.
5) What other design cues can we take from this?
> 1) I've heard talking about Cocoon as a 'XML pipeline engine'... now
you
> are proposing to call it an "web operating system"... the first is too
> little, the second is too much.
Agreed. It's an overstatement.
> 2) an interactive shell isn't really different from what Ovidiu is
> working on (even connecting Emacs directly to the scheme sitemap
engine)
> and I agree that it might be a good parallel to show that he might be
> going in the right direction
Exactly.
> 3) a shell *DOES* *NOT* solve the 'data inward' asymmetry that cocoon
> appears to exhibit. It is a development tool. Possibly a way to author
> the sitemap, but I see *MANY* better solutions.
I was on the weakest ground regarding data flow assymetry. But what
about integrated security? Like the filesystem, is that another concern
island we could wrap into the sitemap? From an application developer's
perspective, security seems like a mess to me (there are so many
options). What if we could make that more seamless? Unless you think
I'm way off base, I'd like to come up with a proposal for this.
Certainly we can and should come up with better administrative solutions
than a shell, but its presence could be comforting to web developers and
administrators, and increase adoption.
Some of these thoughts started out from thinking about the question,
"What is Cocoon?" which I do because I'm always trying to explain it to
people. The website begins with "Apache Cocoon is an XML publishing
framework that raises the usage of XML and XSLT technologies for server
applications to a new level." The beginning of that sentence seems like
it's becoming more and more of an understatement.
Maybe we should say "Cocoon is a web publishing and applications
framework that raises the usage of XML and XSLT technologies for server
applications to a new level."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon as OS
Posted by Stefano Mazzocchi <st...@apache.org>.
[snipped lots of wild yet very interesting thoughts]
If I understood correctly, your stream of thought was something on the
line of:
1) Unix uses pipelines, Cocoon uses pipelines.
2) Unix has interactive shells to compose those pipelines (or the
ability to run scripts for those shells), why shoulnd't cocoon have the
same concept?
I see a number of dangerous assumptions in your logic, please, don't
consider it a critic, but just a review out of my head.
1) I've heard talking about Cocoon as a 'XML pipeline engine'... now you
are proposing to call it an "web operating system"... the first is too
little, the second is too much.
2) an interactive shell isn't really different from what Ovidiu is
working on (even connecting Emacs directly to the scheme sitemap engine)
and I agree that it might be a good parallel to show that he might be
going in the right direction
3) a shell *DOES* *NOT* solve the 'data inward' asymmetry that cocoon
appears to exhibit. It is a development tool. Possibly a way to author
the sitemap, but I see *MANY* better solutions.
Doing parallels is good, but using parallelism as a design suggestion
without considering the weak sides is, IMO, even more dangerous.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org