+10 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 in! > 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. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > In case of troubles, e-mail: [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
