xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Theodore W. Leung" <twle...@sauria.com>
Subject Re: Improving the Apache XML site
Date Wed, 12 Dec 2001 22:32:12 GMT

You can definitely do the Cocoon stuff way faster than I can, since I
haven't looked at 2.0 at all.

On Wed, 2001-12-12 at 02:27, Stefano Mazzocchi wrote:
> I've read the 'xml-deviant' column on xml.com and found it extremely
> interesting for a couple of reasons:
>  1) it's an xml-centric and non-apache-centric view of this project
>  2) it's a user-centric, show-me-the-stuff-that-I-need perspective
> Now, from that perspective, our site sucks. Big time.
>  1) it's slow and heavy, for no reason [this is fixed with the new
> layout]
>  2) it's sub-project oriented: gives no overview of the Apache XML
> Project
> Overall impression: it's a rusty container.
> Why should I (user) trust the technologies it contains?
>                                     - o -
> I personally volunteer to change this and improve it because I don't
> want people coming to xml.apache.org to stop there, I want them to keep
> on getting back and visit our site.
> Here is the plan:
>  1) change the layout in order to speed up the browsing experience 
>     [this is done with the new layout]
>  2) revamp and rewrite the common sections
>  3) place a newscolumn and a project status column on the homepage (just
> like I did several years ago for java.apache.org, go there and take a
> look)
>  4) write the "evolutionary software map" along with explainations on
> where to find stuff, overlap between them, reasons for this overlap,
> community directions and all this.
> Cocoon will generate the site.
> I will write a script (probably an Ant build file) that will gather the
> XML documents from the various CVS modules and then run Cocoon on top of
> those to generate the site and place it live.

Please do this as an ant build file.  Another goal of this should be to
deprecate xml-site.  From working on the layout I found that very few
projects are using it.   Ideally, a cron job would rebuild the site.

I'm willing to help with the content but I just haven't had the time to
get up to speed on Cocoon to take the next step.  Thank you for stepping

> Then I'll write a section of the site that explains how this works and
> where to modify stuff for making it appear there.
> The goals are:
>  1) users must have the impression that the site is 'live' and well
> maintained
>  2) users must have the feeling of the quality of our software from the
> site
>  3) users must find it useful to get back frequently to the site
>  4) users must find it interesting to explore the site and discover our
> technologies but without requiring deep interaction with the code in
> order to get a feeling of it.
> I also have a personal itch to scratch: I would like to have a simple
> way to know the following information from all the different projects:
>  downloads:
>  - downloads per version per week
>  - total downloads per version
>  mail messages:
>  - mail messages per mail list per week
>  - total mail messages per mail list
>  mail list subscribers:
>  - subscribers per mail list per week
>  - total subscribers per mail list
>  CVS commits:
>  - CVS commits per module per week
>  - total CVS commits per module
> The idea is to have a cron-ed script (Perl?) running weekly (on sunday)
> on the apache servers that append this data in comma-separated files,
> for example (numbers are invented):
>  cocoon.downloads:
>    year,week,downloads
>    2001,43,3898
>    2001,44,3849
>    ...
>  cocoon.downloads.totals:
>    year,week,download-totals
>    2001,43,348498
>    2001,44,352849
>    ...
> and so on for every subproject.
> Brian, do you see any problem for this? Don't worry, I'm not asking you
> to do it, we'll provide the scripts, but we need root access to run them
> and add to the cron list.
> Cocoon is then able to transform the above into XML files, process them
> with XSLT stylesheets that generate SVG graphs and then rasterize them
> into graphical images embedded into the site pages.
> Results are:
>  1) the site remains static, no additional load on apache.org machines
>  2) everybody can have a simple window on the status of the subproject
> (not only users, but developers from the other projects and apache
> people outside of xml.apache.org)
>  3) we show off the power of XML technologies for publishing.
> I volunteer to do all the above (but I'll need some help on the above
> scripts since I'm no Perl guru of sort).
> As for DTDs, I'll try to stick with the DTDs we have and adapt the
> stylesheets to the different DTDS (or write adapting stylesheets between
> the various DTDs) In case this is not possible, I'll present here
> alternative plans.
> But keep in mind that the idea is to simplify your life: if this is not
> the case, I have failed and I need to fix that.
> Comments?
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message