On Sun, 30 Jan 2005 23:58:08 +0000, sebb <[EMAIL PROTECTED]> wrote: > On Sat, 29 Jan 2005 19:17:49 -0500 (EST), Henri Yandell > <[EMAIL PROTECTED]> wrote:
> > There are some simple flaws that need fixing, md5/pgp's are shown even > > when not available, and the mirror info, md5 info and pgp info are shown > > even when they're not available. All easy to fix. Also a few missing > > things like links to readme's and change-reports. Also easy enough to fix. > > It might be useful to be able to specify these at individual file > level, as well as higher up. > > e.g. one could have a hash attribute, which would be hash="md5" if > present, and hash="none" if not. Ideally these would default to the > enclosing level. > > Similarly for the signatures, could use sig="PGP" Per file is my plan, wasn't going to kill myself on making it higher up as I think we'd rather not encourage missing pgp/hash's. > > Deployment-wise, my idea would be to replace binindex and srcindex with > > this download.html page. It's small enough that binindex.cgi#tomcat won't > > be a problem when the #tomcat fails. > > But ideally, it won't fail ... By fail, I mean it won't have an anchor to goto :) > > Rather than having projects linking to download.html though, they would > > link directly to their particular page. So ORO would kill its current link > > of binindex.cgi#oro and move to downloads/downloads_oro.html. > > This would mean every project updating their web-pages, which would > take some while to do. Or could the cgi files be rewritten to do this > automatically? > > If not, I think the original links need to be supported, e.g. by > redirecting binindex.cgi and srcindex.cgi to downloads.html and > ensuring that the original names are still present. I was imagining that there'd be a .htaccess redirect for the cgi's to downloads.html. It would be very nice to do it in the code and have the #foo be used to choose a specific download_foo.html page, but I'm not sure how simple that will be. > > The pages are created by taking a downloads.xml file, turning it into > > xdocs-format pages and then turning them into html pages. The interesting > > stuff is in: > > > > http://svn.apache.org/repos/asf/jakarta/site/xdocs/downloads/ > > I like the simpler layout of the downloads section. Much easier to update. > > Though it would be nice if the directory did not have to be repeated > in each link, and ditto the version information. Some of the reptition is because this originally branched out of something larger to index all of the (Java) projects at Apache. ie) specifying the archive url, primary etc in each project. More on that subject when the download pages get dealt with :) > How about something like: > > <group label="Binary" dir="jakarta/tomcat-5/v5.0.28/bin"> > <download file="README.html" title="README (contains packaging > information)"/> > <download file="jakarta-tomcat-5.0.28.exe"/> > <download file="jakarta-tomcat-5.0.28.tar.gz"/> > ... > </group> > > where title is an optional attribute for the link text, replacing the file > name. > dir could be an optional attribute for <download> tags if required - > it would then override the parent attribute. For things like the README.html, I was thinking: <link url="README.html" label="README (contains packaging information)"/>, but having it show file when there's no title sounds good and easy. Sorry for switching email addresses, forgot I don't usually reply to general with this address. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
