cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [OT] cocoon is like windows
Date Fri, 01 Nov 2002 17:59:47 GMT
> So, I came to a conclusion that what Cocoon's documentation lacks is an
> ideological or conceptual papers. 

This is also why I've been pushing for someone to take a lead architectural
role.  It seems that perhaps Stefano doesn't want to be nominated for the
role, but my motivation seems similar to yours.

> The issue is how to build a system? How to integrate Cocoon with the rest
of
> the infrastructure? What tasks are well suited for Cocoon? What kind of
> systems are not fit for Cocoon? 

I'd add; what are the major patterns of usage that Cocoon supports out of
the box?  How do input modules, XSP, Logic sheets, etc. relate or not relate
and which pattern of usage is good for which type of problem?

> Maybe there's a need in documents with 'reference architecture'. It would
> tell the manager or architect, how you, Cocoon developers, envision your
> product co-existing and collaborating with other systems. 

And of course, I'll ask once more, for architecture documentation period:
complete class diagrams anyone? complete flow maps for all the provided
XSLT's? (I know, I'm asking for a lot!)

<snipped some general introduction to what follows/>

> Here's the idea: why not to allow bypass Web GUI in Cocoon. Maybe sitemap
> must be gone too. So, there must be means to build a Cocoon powered system
> in such a way, that I can see what components are in Cocoon and use them
> deliberately. Suppose, I launch URL: /generators/dir and get the list of
> generators. Then I say: 
> /generators/xsp/bla-bla@/serializer/html/ya-da-da
> This will be my command line to launch a generator then forward it to a
> serializer.
> Or like this:
> /generators/xsp/bla-bla@/temp/a
> This would store the output in the temporary URL: /temp/a, so it can be
used
> instead of the generator later on.

It seems that you are proposing a way to expose the architecture to the end
user, almost a sort of administration interface? 

> Then I write my own scripts with things like that, and get my own pipeline
> installed for me. Maybe it's added to my personal sitemap for the current
> session, or forever (with cookies).

Now you're adding some kind of persistence layer to the admin interface...

> This way you tell the user: "this Web site is not your ordinary site. Here
> we provide you with the powerfull XML/XSLT toolkit, which you can use as
you
> like. Pick up your tools, make pipelines, save results in temporary URLs,
> access them later and so on. Customize it, use my site to analyze and
> process your data with my XML tools."

The security implications are "interesting" (in a Chinese curse kind of
way), to say the least...

I think you've invented (or perhaps reinvented) a Web based GUI generator
for Cocoon. Nice to have, but perhaps a separate component from the rest of
Cocoon?

> So, Cocoon will be more like Unix, and less like Windows, i.e. like OS X
:)
> 
> have a good weekend and don't take me too serious :),

Well, the first part of your e-mail seems like an issue that's been getting
a lot of attention lately.  I think it's getting to be a serious issue..


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message