[GAP] Bootstrapping the Ada Academic Initiative

[Marius Amado Alves]

I'm replying to Quinot and cc-ing the GAP, sorry if this is not the 
right procedure. Also, note this is extremely sketchy. It's just a kick 
off. Please discuss and improve.

I think the interface should start simple, and eventually evolve as need 
arise. And I'll discuss the data involved first, and then the interface 
proper.

What do we have? Documentation, teaching materials, software components, 
lab materials (?)... Each such item can take the form of a file or a set 
of files, or eventually a file tree. So the first issue is whether we 
have a flat or treelike structure for the whole. That is, if the item is 
a tree, should the tree structure be provided by the system. I say no, 
for now, make it simple, simple = flat, and if the item is a tree, let 
the author package it into a (zip, arch) file.

Now the attributes of each item. I suggest:

Filename
   the name of the file; entered automatically upon upload
Format
   the usual domain: zip, txt, doc...
Contributor_Id
   equating the GAP user identity, so also automatic
Date
   date and time of the upload; also automatic
Keyterms
   zero or more keyterms from an open set; more below
Content
   the content of the file
Size
   size of content in bytes
Remark
   optional description or notes about the item
Title
   title of the item;
   automatically pre-entered as equal to the Filename
History
   a list of previous uploads;
   maybe a list of downloads also, nice for evaluating usability;
   more below

* MOST SIMPLE INTERFACE *

The main page lists all items, alphabetically by Title.
Each listed Title links to the respective item page.
This main page also has an "Upload new item" button.

* LESS SIMPLE INTERFACE, WITH ITEM SEARCH *

Appropriate for many items say more than 50.

MAIN PAGE
The main page includes a short list of selected item links. Each item 
link leads to the respective item page. The selection of items for this 
list depends on the user mode. If the user is a contributing author the 
list should include his items (ordered by freshness?), as it is probable 
that he wants to update one of them. If the user is not a contributing 
author the items can be selected based on popularity (number of 
downloads), freshness (upload date), or something else. If the user has 
permission a button "Upload new item" also appears here in the main page.

SEARCH GADGET
Page element. Appears in all pages. The usual: a small text field and 
"Search" button for a simple query right away, plus an "Advance search" 
link.

ADVANCED SEARCH
Selective search by at least Title, Keyterms, and whatever keys are used 
in the selection in the main page.

ITEM PAGE
Each item page displays all attributes of the item and a means to 
download it. If the user has permission Update and Delete button also show.

UPLOAD/UPDATE
When a user clicks an Upload or Update button, the usual file selection 
device executes (on the user side). Then a form with input fields for 
Keyterms, Remarks, Title shows, with values pre-entered as expected. If 
the file already exists the History will be incremented with that 
preexisting version. The user checks the fields and clicks Submit. The 
repository gets updated with the new entry. The system stays on the item 
page (?).

KEYTERM INPUT
The keyterm input gadget should allow the user to chose zero or more 
preexisting keyterms or input new ones. The pre-existing keyterms are 
simply the set of keyterms in use. That is, this list grows with every 
new term. Default order alphabetic. No metacategories at this state.

DOWNLOAD
Page element. The usual. Maybe put download shortcuts in the item lists.

NO SCROLL PLEASE
All pages should fit in the screen. Long item lists should be paged, 
with the usual commands (Start, Previous, Next, Last).

* OTHER SUGGESTIONS AND OBSERVATIONS *

Use Mneson, the 100% Ada database system, for this application. 
http://www.liacc.up.pt/~maa. I'll gladly consult for free for this 
application.

Some items may have special licensing terms. For example some might be 
open source, others, like Mneson, strictly not. Any particular implications?

Above in the specification I say "item". But a better name would be 
perhaps "package". And maybe the GNAT packages provided by ACT should be 
integrated with this repository. That would simplify the whole site.