Date: 2005-01-20T19:23:10 Editor: HenriYandell Wiki: Jakarta Wiki Page: DownloadPages URL: http://wiki.apache.org/jakarta/DownloadPages
Dumping some ideas on 'paper' New Page: The Jakarta download page suffers from being a pain in the derrier to use. The current path for a download is either: 1. Jakarta->Downloads(find subproject)->File-on-mirror 2. SubProject->Downloads(find subproject)->File-on-mirror The second is very likely to be the most common download path. Important features are: MD5/PGP details must be seen by the user. .asc/KEYS files must be supplied from the ASF server Other files should come from the mirrors Various types of download, zip, tar.gz, possibly jar. Subprojects have more than one type of file to download, and often have multiple downloads available. The major problems with the current download system is that 1. Users find it tiring to find the subproject on the Downloads page. 2. Users most often skip the MD5/PGP details. ---- The first part of the solution is relatively obvious. The path for the most common download needs to change. Rather than going from Tomcat, to large Downloads page and then to the desired file, it should go from Tomcat to concise page of Tomcat downloads and then to the desired file. How those work/look is still hard to see. Various ideas: 1. Have a download.cgi page which makes assumptions about the location of the KEYS, md5 files etc. It would be invoked as ".../download.cgi?filename=example.zip" and would present a standard and dynamic page for the actual download. Missing in this idea is how to collate the list of files that a subproject wishes to download. 1. Have a downloads.xml file in jakarta-site2 which contains the list of desired download files. It could generate out a whole series of download pages, rather than having to have a dynamic version. The relative location of KEYS/md5 could be attributes. A further idea would be for the download page to contain general project info. The scm repo, the website, the binary downloads, the source downloads, the issue tracker, the mailing lists etc. Commons and Taglibs cause a bit of pain to this idea as the downloads would need to be recursively hierarchical, to at least a second level if not more. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
