Download Package Requirementsby Joseph Bank based largely on the ACS Repository requirements written by Todd Nightingale This is a DRAFT
OpenACS 4.x has a file storage module, so an obvious question is: "Why do we need a separate 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 ScenariosThe download package is intended to support two user roles:
- User (downloading and contributing)
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 occurred 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 InterfaceThe 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 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 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 InterfaceThe 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|
Last modified: $Id: requirements.html,v 1.3 2002/09/13 16:46:34 jeffd Exp $