cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: Cocoon apps Web site hosting
Date Mon, 12 Aug 2002 11:47:50 GMT
Ovidiu Predescu wrote:

>I think what we need to come up with is a general structure for the projects
>hosted. What exactly do we want to offer? This is the list I can think of so
>EUR CVS repository. Some developers might already have their own CVS
>repositories, perhaps at SF, but others may choose to have it hosted here.
If given the karma, I am an experienced CVS hacker. (and I think I 
remember how to pipe it through ssh,
if not I'm sure It'll come to me)

>EUR mailing lists and Web archives for them. Perhaps a better approach is to
>have common mailing lists for all the applications (separated for users and
>developer), so we can maintain a closer community. Should we reuse instead
>Apache's mailing lists?
I would say at least at first, keep it with Cocoon. The more its 
seperated, the more invisible it is.

>EUR Web site presence. I think we need to have a combination of static pages
>with dynamic ones, to show off examples and so on. For the Web site, I think
>we need to maintain a common look and feel, just like Mozilla has for their
>applications. How do people publish their content? Do they have access to a
>staging area to test their site, and then publish it? It would be great if
>we can get some thoughts on what we need here.
For the static ones, that's what Centipede/Forrest are good for (we use 
this for POI and I believe its used
for avalon). For dynamic ones, cocoon with a basic XSLT and an XSP page 
with a CINCLUDE taking its src
from an XSP request parameter. This will provide the basic 
left,top,bottom part and include the content in the
middle. That way we get the *basic* look and feel without bugging the 
heck out of people.

This seems to be largely a duplication of what wants to do, 
perhaps moving it to your server, would
provide us with:

1. The consistant look and feel
2. An already springboarded community with Cocoon and Avalon committers 
making up a part already.
3. The talents of Nicola Ken to help with the *pretty stuff* that I 
can't do as well as increadibly good ideas on how to structure things, 
even if he's totally allergic to documenting it. (I think it gives him 

It would give them

1. Something that doesn't crash all the time like sourceforge....

Seems like a match. The only downside would be this might be a 
subproject rather than *the thing*, but I bet something could be worked out.

Regardless, I still thing we need a cocoon-apps module *here*. More for 
*cocoon-lightweight-example-apps* but thats a bit wordy.


>The last bullet seems to be the biggest item. It would be great if we can
>come up with some more requirements on what it takes to have Web presence
>for these applications, and then sketch out an implementation in Cocoon for

To unsubscribe, e-mail:
For additional commands, email:

View raw message