You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/01/29 18:44:30 UTC
Re: [RT] Cocoon as OS
[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
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