[Jakarta Wiki] Updated: SiteInfo

2005-01-20 Thread general
   Date: 2005-01-20T19:05:22
   Editor: HenriYandell
   Wiki: Jakarta Wiki
   Page: SiteInfo
   URL: http://wiki.apache.org/jakarta/SiteInfo

   no comment

Change Log:

--
@@ -36,7 +36,7 @@
  1. Move Legal link from navbar to bottom of page. -'''DONE'''
  1. Migrate to Subversion - [Site2 Conversion Instructions]. ''Tim''.
  1. Migration of reference pages into Foundation. ''Robert'' - '''ONGOING'''
- 2. Improvement of download pages. Creation of cgi pages. - ''Hen''
+ 2. Improvement of download pages. Creation of cgi pages. - ''Hen'' - 
[DownloadPages]
  3. [EMAIL PROTECTED] considerations. Indexing systems for javadoc, jars, 
downloads etc. IRC channel? Java-based reference pages?
  4. Decide what to do with idedevelopers.html.
  4. SVN information in addition to CVS information.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[Jakarta Wiki] New: DownloadPages

2005-01-20 Thread general
   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]



[Jakarta Wiki] Updated: DownloadPages

2005-01-20 Thread general
   Date: 2005-01-20T19:35:52
   Editor: HenriYandell
   Wiki: Jakarta Wiki
   Page: DownloadPages
   URL: http://wiki.apache.org/jakarta/DownloadPages

   no comment

Change Log:

--
@@ -28,7 +28,7 @@
 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.
+ 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, however the mirror handling would 
still need the current level of dynamism. 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. 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]