 |
 |
 |
Screenshots |  |
|
Download | |
|
Presse | |
|
Kontakt | |
|
Jobs | |
|
Team | |
|
Forum | |
|
Links | |
|
Shop |  |
|
 |
 |
 |
 |
||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LCARS
|
 Verzeichnisbaum |
Auf der obersten Ebene sind alle Fotos in Aufnahmen von Geburtstagsfeiern und Urlaubsfotos eingeteilt - erstere dann nach Personen, letztere nach Ländern und schließlich weiter nach Orten. Dieses System weist aber prinzipielle Lücken auf: wo sollen beispielsweise Fotos von Bertas Geburtstag abgelegt werden, wenn sie ihn auf Mallorca gefeiert hat ? Wenn entsprechende Bilder in beiden Zusammenhängen auffindbar sein sollen, müssen sie auch durch beide Ordner zugänglich gemacht werden, etwa durch Einführung von symbolischen Links. Bei Einführung weiterer Kategorien, etwa des Aufnahmejahres, steigert sich dieser Aufwand zusehends weiter. Darüber hinaus ist eine Verzeichnishierarchie auf der Mitarbeit des Benutzers angewiesen, der geeignete Kategorien für seine Dateien finden und entsprechende Unterverzeichnisse anlegen muss. In der Praxis wird es zudem oft vorkommen, dass Dateien in falschen Verzeichnissen gespeichert werden, so dass sie nicht mehr aufgefunden werden können und „verloren gehen“. Für diese Probleme bietet das LCARS-Dateisystem eine grundlegende und wirksame Lösung.
Ein Grundpfeiler des LCARS-Dateisystems stellt die Verwendung von Metadaten und die Integration von relationalen Datenbanken ins Dateisystem dar.
Metadaten sind Informationen, die nicht zu den eigentlichen Nutzdaten einer Datei gehören, sondern diese beschreiben. Klassische Metadaten sind der Dateiname und das Datum der letzten Änderung einer Datei. Darüber hinaus speichern die meisten Bildformate die Größe des Bildes, also Länge und Höhe in Pixeln. Audiodateien müssen die Samplerate und Bittiefe des Klangs abspeichern. Diverse Multimedia-Dateiformate enthalten zusätzlich noch weitere Metadaten, wie zum Beispiel Titel, Copyright oder das verwendete Aufnahmegerät:
JPEG-Bild mit Metadaten |
Dateien enthalten also heute viele strukturierte Attribute, die für ein herkömmliches Dateisystem jedoch unsichtbar sind: abgesehen von den klassischen Attributen wie Dateiname, Erstellungsdatum und Größe können keine anderen Attribute zum Ordnen von Dateien verwendet werden. Für das Speichern von strukturierten Daten sind klassische Dateisysteme daher ungeeignet, so dass viele Applikationen kleine Datenbanken implementieren, um ihre Nutzdaten abzuspeichern - ein klares Indiz dafür, dass Dateisysteme den Anforderungen dieser Applikationen nicht genügen.
Durch das Verwenden von Metadaten, also beliebigen Attributen für Dateien, verschwimmen die Grenzen von Datenbanken und Dateisystemen, bzw. beide können als äquivalent angesehen werden:
 Beziehung zwischen Datenbanken und Dateisystemen |
Hierdurch lassen sich Datenbanken und Dateisysteme auf logischer Ebene nicht mehr unterscheiden. Als einheitliche Bezeichnung wird der Begriff „Library“ eingeführt, der das Speicherkonzept im Sinne einer Datenbibliothek beschreibt.
DESKWORK setzt ein mehrstufigen Entwurf für das Dateisystem um, der das Betriebssystem vollständig vom unterliegenden physikalischen Dateisystem isoliert. Das Dateisystem setzt sich aus mehreren Domains zusammen, die auf dem physikalischen Dateisystem aufbauen: entweder durch Abbildung von Dateien in die Library, oder durch die Interpretation von Datenbank-Tupeln als Dateien. Ein Sonderfall sind virtuelle Domains, die auf keinem Dateisystem aufbauen, sondern andere Informationen (z.B. das Boot-Protokoll) in Form von Dateien präsentieren. Applikationen greifen nicht mehr direkt auf das physikalische Dateisystem zu, sondern nur noch über Domains. Dies wurde in der Praxis durch Ersetzen der entsprechenden API-Funktionen innerhalb des Betriebssystems realisiert, so dass dieser Vorgang für alle Programme völlig transparent abläuft.
 Architektur des LCARS-Dateisystems |
Intern ist das gesamte LCARS-Dateisystem objektorientiert aufgebaut. Oberste Klasse der rechts dargestellten Vererbungshierarchie ist die abstrakte Klasse DDataAbstract, die eine beliebige Datei eines beliebigen Formats repräsentiert. Neben den obligatorischen Attributen Dateiname, Schlüssel, Typ und diversen Steuerbits definiert diese Klasse eine Reihe von abstrakten Methoden, die von vollständigen Klassen implementiert werden müssen. Durch Aufruf dieser Methoden können Datei-Objekte von außen manipuliert, etwa umbenannt, werden. Die konkrete Realisierung, insbesondere die Funktionsweise und das physikalische Format der beteiligten Domains, bleibt dem Aufrufer dabei verborgen.
Von der abstrakten Klasse DDataAbstract werden auf der nächsten Ebene alle Domains abgeleitet. Bestimmte Methoden, die für alle Dateien der Domain unabhängig von ihrem Format gleich sind, werden dort implementiert, beispielsweise das Umbenennen (Rename) oder Löschen (Kill) von Dateien. Außerdem existieren Methoden zum physikalischen Zugriff auf Dateien, etwa zum Öffnen und Schließen (Open und Close), zum Verschieben des Dateizeigers (Seek) sowie zum Lesen und Schreiben von Daten an der aktuellen Position des Dateizeigers (Read und Write). Diese Operationen werden in geeigneter Weise auf das physikalische Dateisystem abgebildet und sind nur in der Domainklasse selbst sowie allen abgeleiteten Klassen sichtbar (protected).
Zusätzlich enthalten alle Domains die Methode CreateList. Diese Methode bekommt einen Suchfilter übergeben und liefert alle gespeicherten Dateien zurück, die den Bedingungen des Filters genügen. Die konkrete Implementierung kann sich von Domain zu Domain unterscheiden, beispielsweise durch die Verwendung eines geeigneten Indexes. Ein solcher Index kann für alle Applikationen transparent verwaltet werden, da der Zugriff auf Dateien ausschließlich über die von der Domain bereitgestellten Methoden durchgeführt wird. So kann bei jedem Aufruf von Close mit vorherigen Schreiboperationen automatisch eine Aktualisierung des Indexes bzw. der betroffenen Teile vorgenommen werden.
Erst in den Applikations-Klassen werden alle Methoden von DDataAbstract implementiert. Die Objekte von Applikations-Klassen repräsentieren damit eine konkrete Datei, die nach dem Aufruf von Load in aller Regel in den Arbeitsspeicher eingelesen wurde und zur Benutzung bereitsteht. Alternativ kann ein solches Objekt auch von einer Domain erzeugt worden sein, um durch Aufruf der Methode LoadMeta nur die Attributwerte einzulesen und danach in einem Index zu speichern.
Da der Dateiname nur ein Attribut unter vielen ist und im LCARS-Dateisystem keine Schlüsselfunktion mehr hat, können übrigens beliebig viele Dateien denselben Dateinamen haben:
 Normalerweise eine Katastrophe: zwei Dateien mit dem gleichen Namen |
Die stenge Typisierung und die Metadaten von LCARS-Dateien erlauben die Einführung von Funktionen, die über die reine Dateiverwaltung weit hinausgehen. Beim Schreibzugriff (Export) auf Geräte ohne kompatible Library geht der Zugriff auf Metadaten verloren, beim Lesezugriff (Import) muss er wiederhergestellt werden. Diese Aufgabe übernehmen sog. Übersetzer.
Beim Importieren, also Übertragen von Dateien in eine Library, wird das Dateiformat normiert, so dass es einem intern von einer Applikation verwalteten Dateiformat entspricht. Dabei können die Besonderheiten verschiedener Geräte, z.B. die proprietären Metadaten in JPEG-Bildern, die von einem Siemens S65 erzeugt wurden, berücksichtigt werden. Darüber hinaus müssen evtl. zusätzliche Datenstrukturen wie Indexe angelegt oder aktualisiert werden. Beim Exportieren, also Übertragen von Dateien aus einer Library in ein herkömmliches Dateisystem, muss das Dateiformat einem vom Zielgerät oder -dateisystem akzeptierten Format entsprechen. Wird z.B. eine Bilddatei auf eine digitale Kamera übertragen, so muss in jedem Fall ein JPEG-Bild ausgegeben werden. Liegt das Bild in der Library in einem anderen Format vor, ist eine geeignete Konvertierung erforderlich.
Durch dieses Zusammenspiel von Übersetzern und Library lässt sich auf einfache Art und Weise ein sog. „Digitaler Hub“ realisieren. Mit Im- und Export-Modulen für diverse Geräte und Dateiformate kann automatisch ein Datenaustausch zwischen diesen Geräten durchgeführt werden. Ein Anwendungsbeispiel ist ein DESKWORK-PC, an den ein Mobiltelefon und eine Digitalkamera angeschlossen sind. Sie können nun mit ein paar Mausklicks ein Bild von der Kamera direkt als Logo an Ihr Mobiltelefon schicken ! Intern wird dazu das JPEG-Bild der Kamera in den LCARS-Datentyp „Bild“ umgewandelt. Wenn diese Datei nun ans Mobiltelefon gesendet werden soll, wird ein weiterer Übersetzer aktiv, der sie in ein BMP-Bild umwandelt, was das native Datenformat für die Logos aller unterstützter Mobiltelefone ist. Die notwendigen Konvertierungen der Dateiformate werden dabei automatisch und ohne Ihr Zutun veranlasst !
 Von DESKWORK erkannte Geräte (Beispiel) |
In diesen Dokumenten finden Sie weiterführende Informationen zu Datenbanken und Dateisystemen.
