cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [Vote] Improving Cocoon Site
Date Thu, 06 Dec 2001 08:26:47 GMT
Stefano Mazzocchi wrote:
> We have released Cocoon and this is a great thing.
> Now we have to improve the web site a little bit.
> 1) location of Cocoon 1.x documentation:
> I propose to move 
> into
> which I believe it's better because the URI is version-free and
> future-compatible: this means this location identified "the previous
> generation of Cocoon, now considered obsolete, but still used by many".

+0 ... I abstain because i do not yet understand the issues.
I gather that you intend that there will never be another major
version of Cocoon. Otherwise, we will need cocoon/very-old/
as well as cocoon/old/

> 2) graphic look:
> I propose to update the site skin using the new look
> proposed over at Ted, what's the status
> of this?
> where can we find the stylesheets you came up with?
> This mainly because the site is simply too heavy: it's ok to show off
> the power of generating raster images out of SVG files, but this is
> clearly too much.

+1 ... the current website is a huge turn-off. Even local build docs
is very frustrating. I wish for a nice clean look-and-feel like the
Avalon website.

> 3) Clean up documentation: there is a lot to do, but here are things
> that bug me:
> a) there is no visual difference between sections (i.e. User) and pages
> (Who We Are).
> b) there is very little meaning associated with the sections (how in
> hell are readers supposed to know what CTWIG is?)
> c) we should have a "community" section.
> 4) enhance site functionality:
>  a) searching: we must come up with a way to search content, even
> forwarding to Google is better than nothing.

+1 ... However, it is hard to have interactive search on a static
website. Again, if only Cocoon was running on the server, we
could use the new Cocoon-Lucene functionality.

Sure, links to Google might help. However, Google's content
is at least one month out-of-date ... a bit useful, nevertheless.

>  b) community information:
>     - graphs of people subscribed on the mail lists
>     - graphs of messages on the mail lists
>     - graphs of downloads
> I see much more valuable to use the SVG rasterizer for such graphs
> rather than "waste" it to generate the sitebar text. In order to do
> this, though, we need to gather this information.

+1 ... this would be great for us all to see. Yes a far better way
to show off SVG.

> My idea is to have a perl script (or equivalent) run every week that
> comes up with this information and places it on a specific location
> (this should be done for every xml.apache project).

I do not understand how the graphs would get regularly updated
on the website for everyone see. At the moment the site
documentation is only updated on an occasional basis.

Oh, how we wish for a site that was actually running Cocoon
rather than a static web site.

> Unfortunately, the mail list subscription information is reserved by
> root, so we need a high level of access in order to do this (Sam, do you
> have that kind of access level?). The compressed MBOX files can be found
> over at:
>  /www/|dev)
> while the web site logs are in
>  /x2/logarchive/www/2001
> The ideal solution would be to have this processed information already
> XML-ized, but it's probably easier to "append" a line than to add an
> element to an XML file. We could use CSV and do the XML-ization at
> Generation level.
> Something like this would be great:
>  cocoon.list.cocoon-dev:
>  cocoon.list.cocoon-users:
>    year,week,subscribers,messages
>    2001,01,348,983
>    2001,02,358,839
>    2001,03,334,1093
>    2001,03,343,1293
>    ...
> which could XML-ized as
>  <list>
>   <item year="2001" week="01" subscribers="348" messages="983"/>
>   <item year="2001" week="02" subscribers="358" messages="839"/>
>   ...
>  </list>
> or
>  <list>
>   <item>
>    <year>2001</year>
>    <week>01</week>
>    <subscribers>348</subscribers>
>    <messages>983</messages>
>   </item>
>   ...
>  </list>
> which is more verbose, but could be easier to create using SAX events
> and easier to process with XSLT stylesheets (why attributes are so
> neglected in the XML world? bah, I love them so much)
has arguments for and against each. I am still unclear, but
think that i lean towards structured data as elements rather
than attributes. 

> Then we could easily transform this into SVG with an XSLT stylesheet and
> have the raster graph generated automatically without human
> intervention. Again, note that XML-ization of the CSV file can be done
> by a CSVGenerator which is piece of cake to write (I volunteer to do it
> if this is accepted)

Excellent, Cocoon needs a default CSVGenerator anyway.
--David Crossley

> Also, 
>  cocoon.downloads
>  year,week,downloads
>  2001,01,294
>  2001,02,384
> I'm not very good at UNIX administration, so I'd be more than happy if
> somebody else provides the scripts and installs them on :)
> Ok, enough for now.
> Please, place your votes or indicate your
> comments/suggestions/criticism.
> Thanks.
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------

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

View raw message