|
|
## Anforderungen an das System
|
|
|
|
|
|
Es soll eine Online-Packetverwaltung für Curry implementiert werden. Im Folgenden werden verschiedene Aspekte und Funktionalitäten dieser Paketverwaltung genauer spezifiziert.
|
|
|
|
|
|
### Benutzermanagement
|
|
|
* Jeder Benutzer kann einen Account erstellen
|
|
|
* Hierzu werden E-Mail-Adresse und Passwort abgefragt
|
|
|
* Die E-Mail-Adresse muss bestätigt werden
|
|
|
* Es muss ein Passwort angegeben werden
|
|
|
* Der Benutzer kann sich mit E-Mail-Adresse und Passwort anmelden
|
|
|
* E-Mail-Adresse und Passwort können geändert werden
|
|
|
* Ein Account kann vom Besitzer gelöscht werden
|
|
|
* Das Passwort kann bei Verlust zurückgesetzt werden
|
|
|
|
|
|
|
|
|
Es gibt drei Berechtungsstufen, die ein Benutzer haben kann:
|
|
|
* Guest: Gäste sind Benutzer ohne Account. Sie dürfen alle Seiten ansehen und Schnittstellen (lesend) verwenden, aber nicht bearbeiten (d.h. insbesondere keine Pakete hochladen).
|
|
|
* User: User haben alle Berechtugungen der Gäste. Zusätzlich dürfen sie Paketversionen hochladen. Sie dürfen keine Paketversionen löschen, auch nicht ihre eigenen. Für selber hochgeladene Pakete, werden sie automatisch Maintainer.
|
|
|
* Admin: Admins sind User mit zusätzlichen Berechtigungen. Sie dürfen Paketversionen, Pakete und Nutzer löschen, sowie andere User zu Admins machen und als Admins entfernen. Der letzte Admin kann nicht entfern werden.
|
|
|
|
|
|
Maintainer eines Paketes dürfen neue Paketversionen hochladen und neue Maintainer hinzufügen sowie löschen. Der letzte Maintainer kann nicht gelöscht werden.
|
|
|
|
|
|
Zu jedem User gibt es eine Profilseite, die man per Klick auf den Namen erreichen kann. Hier werden alle Pakete angezeigt von denen der User Maintainer ist. Zusatzlich ist einsehbar, ob es sich um einen Admin handelt.
|
|
|
|
|
|
|
|
|
|
|
|
### Paketversion hochladen
|
|
|
User können Paketversionen hochladen. Hierzu gibt es zwei Möglichkeiten:
|
|
|
|
|
|
#### Tar-Ball hochladen
|
|
|
* Es kann ein Tar-Ball der Form *paketname-x.y.z.tar.gz* hochgeladen werden. Dieser muss die richtige Paketstruktur haben und
|
|
|
* es darf noch kein Paket *paketname* existiert (der User wird dann automatisch Maintainer des Paketes.)
|
|
|
* oder der User muss Maintainer des Paketes *paketname* sein und die Versionsnummer x.y.z muss "größer" als die bisher größte Versionsnummer dieses Paketes sein.
|
|
|
|
|
|
#### Package.json hochladen
|
|
|
* Es kann eine *package.json* hochgeladen werden. Diese muss eine gültige package.json-Datei sein und
|
|
|
* einen Verweis auf eine externe Quelle enthalten (z.B. ein Git, siehe cpm) und
|
|
|
* die Quelle muss existieren.
|
|
|
* Mit Hilfe dieser Informationen wird dann eine Paketversion angelegt.
|
|
|
|
|
|
Paketversionen werden ohne weitere Prüfungen für alle sichtbar und in den Index aufgenommen. Sie können bei Bedarf von einem Admin gelöscht werden.
|
|
|
|
|
|
|
|
|
### Paketversion (Tar-Ball)
|
|
|
Eine Paketversion muss die folgeden Dinge enthalten:
|
|
|
* Eine paketbeschreibende Datei (z.B. package.json)
|
|
|
* Den Quellcode
|
|
|
|
|
|
Eine Paketversion kann die folgeden Dinge enthalten:
|
|
|
* Testfälle
|
|
|
* Eine Readme.md, die auf der Paketseite angezeigt wird
|
|
|
* Latex-Dateien, aus denen ein Handbuch generiert wird
|
|
|
|
|
|
Paketversionen sollen keine Binaries enthalten.
|
|
|
|
|
|
|
|
|
|
|
|
### Sichten
|
|
|
Es existieren folgende Listen aller hochgeladenen Pakete:
|
|
|
* alphabetisch
|
|
|
* nach Kategorie
|
|
|
|
|
|
In jeder Liste wird zu jedem Paket folgendes angezeigt:
|
|
|
* Paketname
|
|
|
* neuste Paketversion
|
|
|
* Uploaddatum der neusten Paketversion
|
|
|
* Kurzbeschreibung
|
|
|
* Kategorien
|
|
|
* Maintainer
|
|
|
* Link zur Übersichtsseite der neusten Paketversion
|
|
|
|
|
|
|
|
|
|
|
|
### Suche
|
|
|
Es wird nach Auftauchen des Suchbegriffes in Paketnamen, Maintainern, exportierten Modulen, Kategorien und Kurzbescheibungen gesucht. Die Suche soll nicht zwischen Groß- und Kleinschreibung unterscheiden.
|
|
|
|
|
|
|
|
|
|
|
|
### Übersichtsseite
|
|
|
Zu jeder Paketversion existiert eine Übersichtsseite. Hier werden die folgenden Informationen angezeigt (falls vorhanden):
|
|
|
* Name des Paketes
|
|
|
* Paketversion
|
|
|
* Datum des Uploads dieser Paketversion
|
|
|
* Links zu allen anderen Paketversionen
|
|
|
* Maintainer
|
|
|
* Abhängigkeiten des Paketes
|
|
|
* Compiler Kompatibilitäten
|
|
|
* Lizenz
|
|
|
* Kategorien
|
|
|
* Exportierte Module
|
|
|
* Link zur Dokumentation jedes exportierten Modules
|
|
|
* Test Suiten
|
|
|
* Anzahl der (erfolgreichen) Tests
|
|
|
* Kurzbeschreibung
|
|
|
* Readme (aus Markdown-Datei generiert)
|
|
|
* Link zum Benutzerhandbuch
|
|
|
|
|
|
|
|
|
### Generieren und Anzeigen von Dokumentation und Handbüchern und Test
|
|
|
Aus dem Quellcode soll automatisch eine Dokumentation generiert werden. Diese ist über die Übersichtsseite aufrufbar und kann online aufgerufen werden.
|
|
|
|
|
|
Ist Quellcode für ein Handbuch vorhanden (Latex), so wird auch dieses compiliert und das Ergebnis verlinkt.
|
|
|
|
|
|
Zu jeder Paketversion werden generische Tests durchgeführt (compiliert die Paketversion?) und die Ergebnisse angezeigt (optional werden auch vom Entwickler bereitgestellte Tests ausgeführt, s.u.).
|
|
|
|
|
|
|
|
|
|
|
|
### Ausführen von "sicherheitskritischen" Operationen auf dem Server (z.B. Tests/generieren von Handbüchern)
|
|
|
Es steht eine externe Maschine bereit, an den sicherheitskritische Operationen zur Ausführung geschickt werden können. Dort werden die Operationen in einer Warteschlange eingereiht und ausgeführt. Die Ergebnisse werden an den Webserver zurückgemeldet. Der Webserver soll auch ohne diese Ergebnisse schon alle bis dahin verfügbaren Informationen anzeigen und die Ergebnisse später ergänzen.
|
|
|
|
|
|
|
|
|
|
|
|
### Schnittstelle zum cpm
|
|
|
Es soll eine Schnittstelle zum cpm bereitstehen, über die dieser den Paketindex zur Verfüngung gestellt bekommt und Pakete herunterladen kann. Für den Index kann das bestehende System mittels Git verwendet werden.
|
|
|
|
|
|
|
|
|
|
|
|
### Erweiterung des cpm
|
|
|
Der cpm soll um die folgenden Features erweitert werden:
|
|
|
* Kompatibilität zur Schnittstelle des Webservers.
|
|
|
* Option zum Erzeugen einer neuer Paketversion. Hier sollen (optional) bereits die zur Verfügung steheneden Tests einmal durchgeführt und die Ergebnisse angezeigt werden.
|
|
|
|
|
|
|
|
|
|
|
|
## Optionale Features
|
|
|
|
|
|
### Die Versionsnummer wird auf Semantic Versioning geprüft
|
|
|
Auf der Übersichtsseite wird angezeigt, ob eine Version im Vergleich zur vorhergehenden Version die Vorgaben erfüllt. Z.B. per Farbcode:
|
|
|
* grün: Vorgaben erfüllt
|
|
|
* rot: Vorgaben nicht erfüllt
|
|
|
* grau: Tests noch nicht durchgeführt
|
|
|
|
|
|
### Die Tests in einer Paketversion online ausführen und die Ergebnisse anzeigen
|
|
|
|
|
|
### Benachrichtigungen bei neuer Version einer Abhängigkeit
|
|
|
Die Maintainer eines Paketes x werden benachrichtigt, falls eine Abhängigkeit y der neusten Version von x aktualisiert wird und die neue Version von y "größer" ist, als die von x maximal akzeptierte. Ein Maintainer kann diese Benachrichtigungen abschalten.
|
|
|
|
|
|
### In der Readme einer Paketeversion das Einbinden lokaler Bilder ermöglichen
|
|
|
|
|
|
### Die Suche erweitern
|
|
|
Man soll beim Suchen in der Lage sein auszuwählen, wonach gesucht werden soll (Paketname/Kategorie). Es ist auch möglich die Dokumentationen oder Quelltexte zu durchsuchen.
|
|
|
|
|
|
### Paketversionen vergleichen
|
|
|
Man kann zwei Paketversionen vergleichen und bekommt die Veränderungen im Code angezeigt.
|
|
|
|
|
|
### Package.json Format überarbeiten
|
|
|
Hier könnte zum Beispiel ein Format ähnlich wie das bei cabal verwendete eingesetzt werden.
|
|
|
|
|
|
### User können sich über neue Paketversionen benachrichtigen lassen
|
|
|
Als User kann man Pakete makieren, über die man dann benachrichtigt wird, sollte eine neue Version hochgeladen werden.
|
|
|
|
|
|
|
|
|
|
|
|
## Begriffsklärung
|
|
|
* Paket: alle Versionen eines Paketes
|
|
|
* Paketversion: eine Version eines Paketes |
|
|
\ No newline at end of file |