cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 05:22:17 GMT
At 11:47  8/9/00 -0400, you wrote:
>I actually was interested in Cocoon because I thought it could merge
>multiple pipes into one output. I was in fact using XInclude to include XML
>fragments (like user info, skins, globals) and XSL to shape (filter) the
>results into a another XML hierarchy which would then be styled. E.g. a two
>stage XSLT pipeline. I think this is very powerful.

yep - but not so easy - especially when you cyndicate content from multiple
different sources or when the aggregation mapping needs to be dynamic etc.

>> Aggregation will be served by Jetspeed (an apache project that is
>> currently
>> at but will soon be at Jetspeed
>> does a lot
>> more than aggregate - it mixes in lots of other options.
>True. However, as you mention later, it also seems difficult to learn.

:< yup

>Fair enough. Two comments. First, I thought I read on this list that Turbine
>was going to be used by C2 at some point. I was hoping that it's
>functionality would thereby become available to me.

possibly - in the future. C2 already uses some components (database
pooling) from turbine) but it conceptually a different beast. Currently
Cocoon handles dispatching

>Second, I've begun to look at Cocoon as a two way pipeline and fooling
>around to see if I can make it work (please tell me if it's been done
>already!). That is, each input to the system (e.g. POST) can have multiple
>outputs (e.g. to calling client and backend system), enumerated in the
>sitemap as transformations themselves.

quite possible - thou I would hesitate to say not anywhere as easy as it
should be.

>I think it would be interesting, and the proper separation of responsibility
>in the opposite direction from Cocoon's original design, for the input
>request to generate multiple outbound 'messages' for other systems. Those
>messages should of course simply be XML snippets, which can of course be
>created by XSP and XSL transforms.

it is an interesting approach - make sure you post to the list if you get
it up and running :P

>Am I making any sense? Basically, I could see Cocoon becoming a great way to
>write middleware, not just a publishing system. The benefit of a system like
>C2 where you can insert new elements in the pipeline is that you can let
>Cocoon extend as far in either direction from its center as you want, just
>add or subtract transforms.
>Browser <- HTML <- XSLT <- XML <- XSP <- {JDBC | XInclude | Files | XML-RPC
>| Other}
>Browser -> HTTP -> XSL -> XML -> XSP -> {XML store | MSSQLXML | XQL DB
>XML-RPC | ...}

yep I understand where you are coming from (I tried a similar approach back
in C1.4-C1.6).
However I think I would classify it as "flexibility" syndrome. You can do
it that way but it is not efficient. It also requires back-end writers to
be versed in waaaaay to many technologies and be damn good at those
technologies. Combine this with the fact that it is a PITA to debug XSP or
any dynamically generated language and how *costly* it is and I don't think
you will see such an approach adopted by large websites. 

Mixing content and logic is never a good thing and building excessive
number of general purpose XML processors is a large costly task without any
great benefit IMHO. This is one of the reasons that template engines are
coming in the fore ... I would much rather see a templating XSP rather than
general purpose logic in XSP.
>> So in effect when a request comes in it goes via a "sitemap" (not to be
>> confused with C2s sitemap) that maps request to a web-application. The
>> web-application does it's stuff and then chooses a C2 pipeline to output
>> via. It then fills a "context" with relevent information (like
>> result data)
>> and executes the pipeline with relevent context. Aggregator sits on top of
>> this.
>As mentioned above, while I use what you're describing right now, I'm hoping
>to use only Cocoon in the future.

good luck - I think you will need it :P

>> None of these applications are yet easy to use with cocoon. I have been
>> trying to get people to adopt diferent apache products for a while but so
>> far I have only got them to se cocoon out of these three. There
>> are changes
>> in place to make usage of these products easier (specifically
>> turbine has a
>> simple developers kit setup in progress) but that still leaves a
>> lot of the
>> Integration for you to do. Currently there is also a move to
>> standadise the
>> packaging of all apache products (I believe PMC is or will in future be
>> discussing this possibility) which will help this progress.
>Great! But, uh, who's PMC?

I don't know what it stands for but it is group of people who decide on
directions of Apache projects. Jon (Turbine's original author) was one who
was going to try and standardise project/build structure. I believe Stefano
(original Cocoon author) is also on it.



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message