JabberSoftwareMap - Sprint paper 1

From XMPP WIKI
Jump to navigation Jump to search

Information architecture

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
  • programming language
  • platform(s) (e.g. linux/mac/windows)
  • 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.

File:Jab conceptual database design.png

Physical data structure

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

File:Jab physical data model.png

Latest Database Diagram

File:Entity Relationship Diagram1.jpg

References

The charts are created with ArgoUML and devaki-nextObjects.

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

Retrieved from "https://wiki.xmpp.org/web/index.php?title=JabberSoftwareMap_-_Sprint_paper_1&oldid=13363"