Das Metalab-Betriebssystem ünterstützt Verwaltung und Betrieb des Metalabs sowohl physisch als auch in Software.

Aufgabengebiete

Mitgliederverwaltung (Erfassung, Mitgliedsbeiträge, usw.)
Zugangskontrolle (Kartenleser udgl.)
Shutdown-Plan (was machen wenn man der letzte ist der das Lab verlässt)
Verwaltung der Jabber Mitgliederlisten und Gruppen. (wer Mitglied wird hat sofort alle Members in seiner Kontaktliste)
Single-Sign-On für alle Metalab Services (geteilte userdatenbank zwischen den applikationen)
Anträge an die GV sollen vorbereitet, diskutiert und ev. auch abgestimmt werden können
Inventar-Datenbank, Reservierung/Ausleihung von Gegenständen usw
Eventplanung (Raumreservierung usw)
Lokale Infofeeds: Nächste U-Bahn/Nachtbus, verfügbare Citybikes, Wetter, usw
Irgendwas um die kommunale Pizzabestellung zu vereinfachen :)

Implementation

Grundstock im Python MVC-Framework TurboGears
Offen und interoperabel. Das Metalab OS definiert sich über seine Auswirkungen auf den physischen Raum, nicht durch die spezielle Softwareimplementation
Lose Kuppelung durch externe Dienste auf die durch mehrere Applikationen in verschiedenen Sprachen zugegriffen werden kann (LDAP, Datenbank, ...)
REST Web-App Schnittstelle, ev. auch XMLRPC/SOAP.
Physische Policy Teile des Metalab-OS werden am besten ausgedruckt und an den entsprechenden Orten aufgehängt (z.B. Shutdown-Prozedur beim Ausgang).

Vorläufig wurde ein Subversion (https://dev.metalab.at:10080/svn) und ein Trac (https://dev.metalab.at/trac) installiert. Wer mitmachen will (und daher einen Account braucht) wendet sich bitte an Christoph.

http://things.metalab.at/12f892b5
http://people.metalab.at/c3o
http://spaces.metalab.at/novitaeten

Auf GET-Requests hin werden die Daten je nach Accept-Header (ev zus. je nach "Dateiendung" od. Parameter) in verschiedenen Formaten ausgegeben: HTML+Microformats, XML/RDF [zb FOAF für Personen], RSS/ATOM? etc.
Mit passenden HTTP-Authentication Headern darf man auch DELETEn und PUTen.