JabberSoftwareMap - Sprint paper 1

personal data

 * Full name
 * contact email
 * contact jid
 * photo
 * password
 * uid to login

project informations

 * short name
 * description
 * author
 * homepage
 * Contact JID
 * download URL(s)
 * mailing-list URL(s)
 * web forum URL(s)
 * MUC/groupchat/IRC
 * categories, i.e. Server, Client, Languages, Field-of-Application (Workflow-Management, Communication, News related, Trading, etc.)
 * license, i.e. GPL, LGPL, list of OSI certified licenses
 * levels of compliance
 * xmpp
 * XEP-0073: Basic IM Protocol Suite
 * XEP-0117: Intermediate IM Protocol Suite
 * programming language
 * platform(s) (e.g. linux/mac/windows)
 * subscribers
 * subscribers

release informations

 * Release number / title
 * description
 * direct download link
 * information url / release homepage (for special information sites on unique releases)

Rough architecture
Rough-to-the-jungle architecture diagram

web browser  <-->   web server   <--> application (php/cgi/servlet/application/t.b.d.) |                                                   = <--> J.O. database | xmpp client  <--> j.o jab server <--> jabber bot

Use cases

 * user logs in
 * user/anonymous user views project
 * user changes preferences
 * user adds project
 * user adds release
 * user subscribes to project notifications


 * pipeline manager views pipeline
 * pipeline manager denies release/project
 * pipeline manager accepts release/project


 * user logs out

Activities
All activities result from a corresponding use case. The following activities are not yet finalized.

activity: user logs in

 * user sends login credentials
 * backend checks credentials, in case of ok, continue, else bail out.
 * backend shows user's personal page
 * if user has projects, show button 'my projects' in infobox
 * includes 'add project' in infobox
 * if user is pipeline manager, show button 'my pipeline' in infobox
 * if user has subscribed to projects, show section subscribed projects

activity: user/anomyous user views project

 * user/anonymous user selects project
 * backend loads project description from live database
 * backend formats project description
 * backend shows project description
 * if user is maintainer of project, show special functionality 'add release' button and 'update informations' button

activity: user adds project

 * user wants to create a new project, web project creation page is displayed.
 * user fills in informations
 * server checks data and in case of error displays project creation page with error message, else continue
 * server needs to check if the shortname is unique
 * server stores informations in the temporary database and marks them as to be acknowledged
 * server informs user about current status
 * server sends notification to pipeline managers
 * pipeline managers log in
 * pipeline managers accept or reject project (see corresponding activity)

activity: user adds release

 * user wants to add new release
 * user must be within a project overview
 * if user is maintainer of project, show possible 'add release' button
 * user selects add new release
 * backend shows new release overview page
 * user fills in informations
 * user sends form
 * backend checks informations
 * check for completeness
 * check if there is no other release in the pipeline
 * in case of errors, backend informs user, else continue
 * backend adds release to temporary database with flag 'to be acknowledged' ( means, pipeline_status = 0)
 * backend informs release managers
 * backend shows informations on the process to user

activity: user subscribes to project notifications

 * user wants to subscribe to project notifications
 * user must be within a project overview and must not be subscribed already
 * user clicks subscribe
 * server adds user to subscribers for this project
 * server shows subscription ok

activity: pipeline manager views pipeline

 * pipeline manager wants to view all release projects
 * backend generates list with all to-be-released-projects based on flag in temporary database
 * + backend generates list with all to-be-released releases based on flag in temporary database
 * backend generates complete list on one oage.

Note: to be acknowledged projects or releases have flag pipeline_status set to 0.

activity: pipeline manager denies release/project

 * pipeline manager views release or project informations
 * pipeline manager clicks 'deny'
 * in case of project, backend checks if the project exists in the final database already, if so, it restores the informations from the final database into the temporary database
 * in case of release, backend checks if the release exists in the final database already, if so, it restores the informations from the final database into the temporary database
 * backend sets comment in database
 * backend informs maintaining user about denial
 * backend shows pipeline overview

activity: pipeline manager accepts release/project

 * pipeline manager views release informations
 * pipeline manager accepts release
 * backend stores pipeline manager id in the database for that release
 * backend marks release in database as accepted
 * backend generates release informations
 * backend shows pipeline overview.

activity: user logs out

 * backend kills session
 * shows log out teaser ;-) [just a joke]

Technicals

 * There exist two duplicate databases, one for temporary / to-be-ack working and one for live working

Notifications
The hierarchical project tree allows subscriptions on various levels.

Example of an project tree: /projects /java /projectA /projectB /projectC /projects /client /projectA /server /projectB /projectC

If at one level of this hierarchy an event is generated, all subscribers of higher tree nodes are automatically informed, too (see PubSub). In this simple example a user may subscribe to any node in this hierarchy. If the user subscribes to /java, he is automatically informed whenever there was activity beneath java. If a user subscribes to projectA, he is only informed about activity for projectA. Of course there can be redundant subscriptions, for example a subscription for /java and /client. The notification system must be smart enough to filter out these redundancys.

Finalization

 * When a project is finalizes or released, the system moves the entire dataset from the temporary database into the live database.
 * When a project has to be restored from the current live system, i.e. due to denial of a task, the entire project's dataset is moved from the live system into the temporary database.

Database design
As said, two similar databases exist:
 * Database SOFTWARE_MAP_LIVE
 * Database SOFTWARE_MAP_INTERMEDIATE

Conceptual Diagram
This conceptual data diagram is not yet final. It is work in progress.



Physical data structure
This physical data structure is not yet final. It is work in progress.



Further ideas and informations

 * Need to add a 'link to us' button
 * Season skinning
 * Project rating
 * Light bulbs as indicators
 * Project comments
 * Top viewed projects
 * Top rated projects
 * Project of the month
 * Project of the year
 * "Vote your favorite" Cup Contest

Current test release
http://dyndna.dynalias.org:8000/jabber/staudinger/jabber