Download Package Requirements

by Joseph Bank based largely on the ACS Repository requirements written by Todd Nightingale

This is a DRAFT

I. Introduction

OpenACS 4.x has a file storage module, so an obvious question is: "Why do we need a seperate download module?" The download module is targeted at a different usage pattern and interface. The intent of the download module is to provide an online repository for the public (or pseudo-public) distribution of infrequently modified files. The ACS 3.4 download module, used at http://www.arsdigita.com/download for distribution of software provided by ArsDigita, and the acs-repository, used at http://www.arsdigita.com/acs-repository for distribution of ACS packages, are the prime examples of this usage pattern. While the file-storage module could be used for this purpose, it would be an akward fit. Additionally, we would like to track who has downloaded the file and have the ability to spam or charge those users as appropriate.

II. Vision Statement

There are thousands of independent developers all over the world writing their own OpenACS packages. Without a canonical distribution point finding the packages you need becomes a formidable task, forcing developers to duplicating each others efforts. The download module allows us to setup a package repository service for users to upload their own packages and download contributed packages in order to facilitate true development collaboration.

III. System/Application Overview

The OpenACS download package provides an application for managing file distribution.

The package consists of the following components:

A data model for storing files.
A data model for storing meta-information about files.
A data model for storing information about who has downloaded files.
A user interface for displaying available files.
A user interface for downloading files.
A user interface for uploading files.
A user interface for administering files.

IV. Use-cases and User Scenarios

The download package is intended to support two user roles:

User (downloading and contributing)
Administrator

Joe Contributer (currently working for Joe.com) writes a piece of software used to do knowledge management (KM) for the ACS. He packages his code using the APM. Joe feels that others could gain from using his new package so he uploads it to the OpenACS Package Repository. Since it is in APM format, in one step a package, version, vendor, owner and description data are all uploaded (extracted from the .info file).

Jane Admin who installed and configured the download package chose to not allow users to download versions pending approval. That forces her to download Joe's package from the admin pages and install it. She notices that it isn't malicious in any way and doesn't harm her OpenACS installation so she approves it to go live on her package repository. Joe is informed via email that his package was approved (because Jane set this configuration parameter).

Don Downloader is scanning through the most recently uploaded APMs on a package repository and finds Joe's KM package. He notices that many other users have downloaded the package and have made comments praising the package as well as Joe.com. Since Ben is a follower by heart, he decides to download the package as well and install it on his system. (Ben's crafty friend Alyssa later informs Ben that he could have just had the APM install directly from the repository url).

Benny Beancounter loves to learn about who's downloading files from his site and what reasons they give for downloads. On a frequent basis, Benny visits the download packages admin pages and views a report of how many downloads occured for each file. He then drills down on a particular file and views a list of the users who downloaded the file and their specified reason for downloading.

V. Related Links

Design Document - not present.
Some Features

VI.A Requirements: Datamodel

10.0 Versioned File Storage

OpenACS Download must provide versioned file storage.

20.0 User Tracking

OpenACS Download must store information about which users have downloaded which files (including versions).

20.0 Package Based Meta Information

OpenACS Download must be able to store arbitrary meta information on a per package basis. i.e. All files provided by this instance of the package require the fields x, y and z.

VI.B Requirements: Users Interface

The requirement of the user interface is to enable the user to access package versions in the repository and upload his own packages and versions.

100.0 Define a Package (must be logged in)

100.1 The user must be able to create a repository package by specifying all the necessary information:

package key (unique)
package name
package url (unique)
owner information
vendor information (optional)
Description
Description Format
package type
package category (optional)

100.2 If the user fails to provide the required information the package cannot be created.
100.3 If the tries to add a package with overlapping values in any unique field the package cannot be created.
100.4 All the package information should be edit-able after package creation.

110.0 Manage Package Permissions (must be logged in)

110.1 The user may grant or revoke write and administer privileges on any package which he/she has administer privileges.
110.2 The user who creates a package starts with write and administer privileges.

120.0 Upload Versions (must be logged in)

120.1 The user must be able to upload versions of a package to the repository. These versions contain the actual package content in a tarball (gzipped tar archive). Along with these versions come their own meta-data:

version number (like 1.1 or 1.2.3d4)
version url (unique)
Description
Description Format

120.2 If the user fails to provide the required information the version cannot be created.
120.3 If the user tries to add a version with overlapping values in any unique field the package cannot be created.
120.4 If the user tries to upload a version which already resides in the repository the version cannot be created.
120.5 If the user will not be able to attempt to upload versions into packages which he does not have write permission on.

130.0 APM Auto-load (must be logged in)

130.1 When a user is uploading an APM all package and version information must be automatically entered (without additional user prompting).
130.2 If it is the first version of a package all package information must be added to the repository as well as version data.
130.3 If the package already exists then all package information conflicts must be reported to the user.

140.0 Package Downloading
Users must be able to access packages once they are live on the site.

140.1 Users must be able to view the package meta-data without downloading the package.
140.2 Users must be able to download the actual package data.

150.0 User commenting

A logged in user must be able to comment on vendors, packages, and versions.

VI.C Requirements: Administrator's Interface

The requirement of the administrator's interface is to enable administrators to approve or reject package versions as they are uploaded by users. Naturally any site administrator would have rights on all the packages in the repository 200.0 Approval Parameters

200.1 Administrators must be able to set whether or not packages pending approval are accessible to users.
200.2 Administrators must be able to set whether or not users are notified when their uploaded packages are approved or rejected.

210.0 Version Approval

The administrator should be able to approve or reject any submitted package version, and enter a comment as to why the version was rejected or approved.

VII. Revision History

Document Revision #	Action Taken, Notes	When?	By Whom?
0.3	Minor edits. Few typos & links fixed. ACS changed to OpenACS.	2/16/2002	Vinod Kurup
0.2	Edited to include original requirements from the ACS Repository	12/10/2000	Joseph Bank
0.1	Creation	11/23/2000	Joseph Bank

Last modified: $Id: requirements.html,v 1.2 2002/02/23 05:15:35 vinodk Exp $