cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Vote] Improving Cocoon Site
Date Thu, 06 Dec 2001 11:53:22 GMT
David Crossley wrote:
> 
> 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
> >
> >  http://xml.apache.org/cocoon1
> >
> > into
> >
> >  http://xml.apache.org/cocoon/old/
> >
> > 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/

No, I indend that will never be more than two incompatible versions
supported, the current and the old.

> > 2) graphic look:
> >
> > I propose to update the site skin using the new xml.apache.org look
> > proposed over at general@xml.apache.org. 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.

Ok, will do it.
 
> > 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.

Oh, I'd love to have Cocoon serve its own pages, believe me, but apache
machines are simply too loaded for that (and I don't personally have the
access level to be able to run this, nor I want that responsability on
such an important servers since I'm no system adminitrator of any sort!)

Maybe we could use Nagoya (Sun E4500, *big* beast!) for that and
redirect: Sam, you have access to that machine, right?
 
> >  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.

What about moving over to nagoya? it's solaris machine so java support
rocks, plus it has more RAM than we need :) It could also be a wonderful
load test.
 
> > 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/xml.apache.org/mail/cocoon-(users|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)
> 
> http://xml.coverpages.org/topics.html#elementsAndAttrs
> has arguments for and against each. I am still unclear, but
> think that i lean towards structured data as elements rather
> than attributes.

My personal design pattern is: if it's only one and doesn't require
nesting, should be an attribute.

This results, IMO, in increased readability and reduced verbosity
without any degradation in expressivity.

But that's my personal opinion only.

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

Shouldn't take long to write.

You guys come up with the CSV files and I write the generator, ok? :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message