Re: [OT] cocoon is like windows

[Stefano Mazzocchi]

[EMAIL PROTECTED] wrote:

So, what's Cocoon? What paradigm lies beneath it?

I've used these two analogies to explain what Cocoon is, depending on what the person want to use Cocoon for (most of the time, I end up using both because it's hard to differentiate):

1) for people using Cocoon for system integration, I call it a "software glue for the web". It is a framework that 'glues' together many different systems by adapting them on a common XML layer.

2) for people using Cocoon for web development, I call it "web lego" (since component-oriented programming sounds too technical and many don't see the difference between COP and OOP). The notion is: Cocoon is like Lego: we design the shapes of the components and how they can work together, then you can use the ones we ship in our box, or write your own. The examples, provides suggestions on how to use the software, just like any lego box comes with instructions on how to do something.

I see it this way: it's a Web GUI to a collection of components

:-) Cocoon is used extensively in pure B2B applications, expecially in banking environments. Where is the GUI on that?

I see an analogy with Unix.

Sure, both Cocoon and Unix use the same design pattern.

One of its stregthes is that it has many
utilities which can cooperate with each other. Cocoon is somewhat similar in
that. The difference is that in Unix any user can write his own scripts, in
Cocoon he can't. So, Cocoon in this sense is Windows: run your app and don't
bother with customizing the system for your needs.

Sorry, but that's very lame argument. In unix if you define your pipelines in a purely declarative fashion, that's due to the nature of use of Unix.

In Cocoon, you use a declarative syntax because the control is inverted (the client asks the server). And today, with the flowscript, you can decouple the flow logic (inherently procedural, so scripted) from the resource production logic (inherently declarative, so defined in markup)

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.

A cocoon console? that's wild :)

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).

I really don't

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."

do you work for microsoft? :) it sounds like the kind of very stupid ideas people at microsoft get and turn an operating system into a humangous security hole.

So, Cocoon will be more like Unix, and less like Windows, i.e. like OS X :)

No, it would be much less Unix and more Windows, at least from a security perspective.

have a good weekend and don't take me too serious :)

Nah, I'm already used not to take seriously architectural choices driven by parallel analysis of systems, instead of looking at what they were written to accomplish.

Next time, instead of performing differential analysis on two systems that do totally different things and propose the changes according to lack of parallelism, come up with some use-case scenarios and build from there. You are attacking the problem coming from the opposite direction and this leads to *serious* architectural mistakes (ask around at Redmond, I think they understood this by now :)

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]