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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
