Welcome to codeartists.org

Eph ist mein Versuch, alleine einen x86-Compiler für eine eigene Programmiersprache zu entwickeln. Bevor ich jedoch darauf eingehe, wodurch sich Eph denn nun auszeichnet, möchte ich zunächst einmal die Probleme bestehender Programmiersprachen erläutern, mit denen ich mich vor und während der Entwicklung von Eph konfrontiert sah und immer noch sehe.

Problem: Hierarchie der Klassen. Statische Elemente einer Klassen machen Klasse quasi selbst zum Objekt ("Hack").

Problem: Konstruktor vs. Setter Dependancy Injection. Lösung: Builder-Modus?

Problem: Wie greift man auf Schnittstellen zu? Wie sind sie definiert? Wie lauten die Parameter, in welcher Reihenfolge müssen sie angegeben werden usw.? Lösung: Benennung der Parameter, Fluid API?

Grundlage von virtualme ist das Prinzip eines verteilten sozialen Netzwerks: Benutzer wählen einen beliebigen virtualme-Anbieter, melden sich bei dessen Server an und erhalten dafür eine ID benutzer@anbieter.tld. Auf dem Server ist seine Kontaktliste hinterlegt, wobei es keine Rolle spielt, ob die Kontakte bei dem selben oder einem anderen Anbieter (Server) angemeldet sind. Die Dezentralisierung kommt dadurch zum Ausdruck, dass ein Nutzer stets über seinen Server handelt. Er nutzt ihn zur Kommunikation mit anderen Kontakten (Benutzer 1 schickt die Nachricht an seinen Server, der sendet sie an den Server von Benutzer 2, der sie wiederum an ebendiesen Benutzer weiterleitet). Genauso muss ein Service erst beim Server anfragen, bevor er mit dem Nutzer in Kontakt treten kann. Insofern hat virtualme starke Ähnlichkeit mit XMPP / Jabber (durch welches es auch inspiriert wurde), erweitert es jedoch ausdrücklich nicht. Denn leider musste ich feststellen, dass meine Pläne für virtualme kaum kompatibel mit XMPP sind

Eine weitere Gemeinsamkeit zwischen XMPP und virtualme gibt es noch: Bei beiden handelt es sich nur um ein Protokoll, jedoch in keinster Weise um Software.

Zentrales Konzept von virtualme ist das der Datensätze (records), die der Nutzer auf dem Server hinterlegen und deren Veröffentlichung er über Tags steuern kann (s. unten). Das Format der Datensätze wird über XML Schemas und damit über XML Namespaces definiert, denn die Daten werden als XML strukturiert und übermittelt. Datensätze sind damit nicht klassisch linear im Sinne einer SQL-Datenbank zu sehen, sondern können hierarchische Tiefe besitzen. Die Speicherung der Datensätze kann jedoch höchst unterschiedlich ausfallen. In den meisten Fällen dürfte sich aus Performance-Gründen eine SQL-Datenbank im Hintergrund anbieten. Die Entscheidung darüber liegt jedoch beim Server. Er könnte beispielsweise auch modular aufgebaut sein, sodass Datensätze abhängig von ihrem Typ auf ihre jeweilige, besonders effiziente Art und Weise gespeichert werden.

Dadurch, dass es sich bei Datensätzen um einfaches XML handelt, ist gleichzeitig auch jedes mögliche Format denkbar, in welchem der Nutzer seine Daten auf dem Server hinterlegt. Es könnte sich bei den Datensätzen u.a. um Profilinformationen, Bilder, Videos, Dokumente, Termine oder aber auch Nachrichten (s. unten) handeln. Der Server stellt insofern eine riesige Datenbank dar. Es ist jedoch klar, dass es Standards in Bezug auf das Format von Datensätzen geben muss, damit die Kompatibilität zwischen den Programmen auf Seite der Nutzer, Server und Services gegeben ist. Die Rolle der Festsetzung von Standards übernimmt daher codeartists.org als Entwickler von virtualme. Gleichzeitig ist es dem Serveranbieter jedoch jederzeit gestattet, dem Datensatzformat Beschränkungen aufzuerlegen und sogar bestimmte Formate zu verbieten oder nur bestimmte zu erlauben (etwa auch zur Einrichtung eines kostenpflichtiger Dienstes, in dessen Rahmen der Nutzer neue Datensatzformate freischalten lassen kann).

Wie bereits angesprochen, kann der Nutzer anderen Nutzern (seinen Kontakten) erlauben, auf die von ihm hinterlegten Datensätze lesend, aber auch schreibend zuzugreifen (standardmäßig ist jedoch jeglicher Zugriff verboten). Er kann dazu die Datensätze mit Tags versehen, die zum Einen beschreibenden Charakter haben, zum Anderen die Inhalte für Kontakte freischalten, die vom Benutzer mit dem selben Tag gekennzeichnet worden sind. Tags können wiederum hierarchisch geordnet werden, sodass ein Hinzufügen des Tags "Mein Software-Projekt xy" gleichzeitig den Tag "Software-Projekte" zur Folge haben könnte, was den Umgang mit vielen Tags vereinfacht.

Wie greift man auf Datensätze zu? Wie aktualisiert man sie? Dieses Problem stellt sich natürlich, wenn man sich für Datensätze auf XML-Basis entscheidet. Schließlich gibt es keine Spalten im klassischen Sinn, wenn alles wieder untereinander verschachtelt werden kann.

Zugegeben, es gibt XQuery. Doch diese Sprache weicht nicht unwesentlich von den Anforderungen an eine Abfragesprache ab, die simpel, flexibel und für reine Übertragungen zugeschnitten sein soll. Mit letzterem Punkt ist gemeint, dass zu keinem Zeitpunkt ein echter Zugriff auf die Datenbank möglich sein soll. Die Sprache soll also ausschließlich eine zusätzliche Abstraktionsebene zur eigentlichen Datenbank bilden. Würde XQuery (oder SQL) eingesetzt werden, müssten die Anfragen jedoch vorher immer dahingehend überprüft werden, dass sie auch nur das tun, was sie tun dürfen. Darüber hinaus spricht gegen XQuery, dass es bisher keine Möglichkeit bietet, die Datenbank zu verändern oder zu aktualisieren (bzw. die entsprechende Erweiterung bisher noch nicht vom W3C als Empfehlung verabschiedet wurde, geschweige denn schon in XML-Datenbanken implementiert wurde).

Davon abgesehen stellte ich mir die Anforderung, dass stets eine vollständige Validierung der Anfrage auf Server-Seite möglich sein soll. Vollständig heißt, dass eine Anfrage nicht nur zunächst in Bezug auf die Syntax geprüft wird und erst bei der Ausführung die semantischen Regeln zum Einsatz kommen, sondern, dass beide Überprüfungen gleichzeitig erfolgen. Zur Semantik zählen insbesondere die Regel, dass alle Felder (hier: Tags) existieren müssen, und die, dass ihre Datentypen korrekt verwendet werden. Zusammengefasst bedeutet dies, dass das ursprüngliche Format des Datensatzes eingehalten werden muss. Da sich dies jedoch nur auf Basis des XML Schemas des Datensatzes entscheiden lässt, musste eine Sprache her, die auf XML basiert, und bei der die Namen von Feldern (lies: Tags) nicht innerhalb Attributwerten vorkommen können. Letzteres würde die Validierung anhand eines XML Schemas ansonsten unmöglich machen.

Es musste also eine neue Abfragesprache her. Ich habe mir in den letzten Wochen dazu intensive Gedanken gemacht und habe versucht, vom klassischen SQL-Ansatz wegzukommen. Was dabei herausgekommen ist, ist FlexQL. FlexQL basiert im Wesentlichen auf der Idee, XML-Strukturen und -Tags verschiedener Namespaces miteinander zu vermischen. Eine Anfrage an den Server besteht also im Grunde aus einem leeren Datensatzgerüst, welches mit Angaben in Bezug auf Modifizierung (UPDATE) und/oder Ergebnis (SELECT), Selektion (WHERE), Sortierung und Limits versehen wird.

FlexQL-Queries werden dadurch im Vergleich zu vergleichbaren Sprachen wie XSLT unheimlich kompakt (SELECT und UPDATE können zusammen durchgeführt werden), darüber hinaus sind ihnen auch eine gewisse Ästhetik und Intuitivität nicht abzusprechen.

Selbstverständlich müssen FlexQL-Queries auf Server-Seite in geeignete Anfragen für die jeweilige Datenbank umgewandelt werden. Dies hängt natürlich vor allem von der Struktur des Datensatzes ab. Einfache, mehr oder weniger lineare Formate sollte ein Server eins zu eins über eine relationale Datenbank abbilden können, eine generelle Lösung für Datensätze beliebiger Komplexität scheint mir jedoch nicht möglich zu sein.

Leider hat FlexQL auch darüber hinaus Grenzen. So habe ich bisher beispielsweise noch keine zufriedenstellende Lösung für komplizierte Joins gefunden.

Bisher wurde nicht darauf eingegangen, wie der Benutzer dies alles macht, d.h. auf seine Datensätze zugreift, Tags erstellt, usw., da es sich bei virtualme in erster Linie nur um ein universelles Protokoll handeln soll. Insofern sind alle Zugriffswege (Weboberfläche, spezielle Desktopapplikation, Handy) gleichermaßen möglich und je nachdem, was die jeweilige Software beabsichtigt, kann sie dem Nutzer eine oder mehrere Datensatztypen zugänglich machen, die der Nutzer dann wiederum - abhängig von der Software - betrachten und verwalten kann. Denkbar wären an dieser Stelle ein Instant-Messenger, eine Art dezentralisiertes YouTube, ein Programm zum Verwalten und Austauschen von Bildern, ein Kalender für mobile Endgeräte, der seine Daten mit dem Server synchronisiert, und vieles, vieles mehr.

Um Software

Auf gleiche Weise soll auch die Server-Software vollständig austauschbar und möglicherweise über Erweiterungen anpassbar sein.

Mit virtualme soll der Wunsch eines Single-SignOns endlich Realität werden. Die Umsetzung dieser Idee ist bisher auch deshalb auf der Strecke geblieben, weil ein Single-SignOn alleine nicht ausreicht. Der Dienst, bei dem man sich anmeldet, muss auch Daten mit dem ID-Server des Nutzers austauschen können bzw. Daten vom Nutzer erhalten können. Dies ist mit OpenID bisher nur sehr eingeschränkt möglich. Was bringt es dem Benutzer, wenn er sich zwar Registrierungsmails erspart, das Profil jedoch trotzdem noch vervollständigen und aktualisieren muss?

Hier setzen die Services im Rahmen von virtualme an. Bei einem Service kann es sich im Prinzip um eine beliebige Anwendung Dritter handeln, die Daten vom Nutzer bei seinem Server erfragt und auch über Änderungen dieser benachrichtigt werden kann (s. unten). Dazu muss der Nutzer noch nicht einmal in irgendeiner Weise bei dem Service angemeldet sein (im Sinne einer Registrierung bzw. eines Logins). In jedem Fall muss sich der Service aber beim Server registrieren, sodass der Nutzer in der Lage ist, Inhalte und Service mit entsprechenden Tags zwecks Veröffentlichung zu versehen. Der Service erhält dabei ein eindeutiges Token, was ihm beim nächsten Mal zur Reauthentifizierung dient. Natürlich hat der Nutzer auch die Möglichkeit, Services abzulehnen oder sich bei ihnen wieder abzumelden. Der Dienst hätte dann natürlich die Pflicht, alle Daten, die er vom Nutzers gespeichert hat, zu löschen.

Als Service vorstellbar wäre beispielsweise die Website des Nutzers selber, auf der er Artikel, Bilder und Videos veröffentlicht. Denkbar wären aber genauso Applikationen (ähnlich der auf Facebook), die als Service Informationen über den Nutzer erhalten, ihre eigenen Daten jedoch an einem anderen Ort speichern. Oder aber der Nutzer gestattet den Services, auch schreibend auf Teile seiner Daten zuzugreifen, sodass sie Informationen bei ihm ablegen können.

Im Fall solcher externer Anwendungen, die nicht nur Daten des Nutzers lesen, sondern ihm auch auf ihn zugeschnittene Dienste bieten, ist es erforderlich, dass der Nutzer sich vorher authentifiziert. An dieser Stelle kommt der Single-SignOn ins Spiel. Der Nutzer könnte sich durch ihn auf jeder Drittseite anmelden, die dann automatisch in die Liste seiner Services aufgenommen werden würde.

Insgesamt hat der Nutzer hat also stets die vollständige Kontrolle über die Websites und Services, bei denen er mit seiner virtualme-ID registriert ist und mit denen er seine Daten teilt.

Die starke Integration des virtualme-Netzwerks in den Alltag soll im Wesentlichen durch Subscriptions (Abonnements) & Synchronisierung vorangetrieben werden.

Im Rahmen von Subscriptions sollen sowohl Nutzer als auch Services in die Lage versetzt werden, sich über Aktualisierungen der Datensätze anderer Nutzer informieren lassen zu können (nur neue, nur Änderungen oder beides). Der Server versucht in solch einem Fall eine Verbindung zum Nutzer oder Service herzustellen (sofern sie nicht bereits besteht) und sendet ihm die IDs der Datensätze, die verändert wurden. Nutzer oder Service haben daraufhin die Möglichkeit, die Daten vom Server zu laden.

Somit wird der Wunsch Realität, dass der Nutzer seine persönlichen Daten wirklich nur noch an einer Stelle ändern muss, wie es schon oben angesprochen wurde.

Zu den Datensätzen zählen aber selbstverständlich auch der Status (Online, Offline, Abwesend o.ä.). Damit ist klar, dass selbst elementare Dinge, wie die Benachrichtigung darüber, dass ein Kontakt on- oder offline geht, auf dem System der Subscriptions basiert. Es ergeben sich aber auch andere vielfältige Anwendungsmöglichkeiten, z.B. ähnlich wie bei Twitter chronologische Angaben darüber, was der Nutzer gerade macht oder gemacht hat.

Die Sicherheit des Benutzers und dessen vollständige Kontrolle über seine Daten, die er auf dem Server hinterlegt, stellt einen der wesentlichen Kernpunkte von virtualme dar. Dies äußert sich bereits darin, dass der Nutzer seinen Anbieter frei wählen und ggf. auch seinen eigenen Server einrichten kann. Das virtualme-Netzwerk ist also niemals von einem einzigen Anbieter abhängig. Der Nutzer kann stets einen Anbieter wählen, dem er vertraut und von dem er denkt, dass seine Daten bei ihm sicher sind.

Um darüber hinaus die Sicherheit der Übertragung der Daten zu gewährleisten, kann der Nutzer festlegen, dass die gesamte Übertragung mithilfe TLS oder eines Public/Private-Schlüsselpaares verschlüsselt erfolgen soll.

Ob es auch sinnvoll ist, die Daten auf den Servern verschlüsselt zu speichern, muss noch genauer untersucht werden. Vermutlich ist das nicht der Fall, denn wie sollten dann die Daten ohne Zutun des Benutzers (d.h. ohne seinen privaten Schlüssel) an seine Kontakte übermittelt werden?

Um die reibungslose Kommunikation mit Benutzern (Clients), Servern (Peers) und Services zu ermöglichen, warten virtualme-Server an den Ports 31337, 31338 und 31339 auf eingehende Verbindungsanfragen von Clients, Peers und Services. Das Protokoll basiert dabei auf XML, welches eine größtmögliche Flexibilität ermöglicht. Das Prinzip des XML-Streams und der XML-Stanzas wird dabei weitestgehend von XMPP übernommen.

Das bedeutet, dass ein solcher XML-Stream insgesamt vom Beginn bis zum Ende der Verbindung einem validen XML-Dokument entspricht. Jeder Knoten im Root-Tag (<stream>) entspricht dabei einer Signal, einer Nachricht, einem Auftrag (in XMPP auch XML-Stanza genannt). Er ist damit die atomare Einheit, in denen beide Seiten Anfragen bzw. Antworten übermitteln.

Das Projekt wird im Moment von mir alleine geführt. Der Entwicklungsstand des in Java geschriebenen Server-Programms kann auf der BitBucket.org-Projektseite eingesehen werden. Dort finden sich auch die XML Schema Definitionen (XSDs) der XML-basierten Protokolle.

Abgesehen davon ist für die Zukunft auch ein Web-Interface geplant, über welches ein Account und gleichzeitig auch der Server einfach verwaltet werden kann. Dies wird also gleichzeitig das erste Client-Programm für virtualme sein.

Solltest Du Vorschläge oder Anregungen haben oder Dich sonst in irgendeiner Weise (vielleicht am Web-Interface? ;-)) beteiligen wollen, würde ich mich freuen von Dir zu hören.

For virtualme's protocol specification I was in need of a good and comprehensive XML editor. Unfortunately, there aren't many of this kind that are also free. So I tried out SyncRO Soft Ltd.'s <oxygen/> XML Editor for a trial period. In the end I was already on the verge of purchasing a license, but the price of $48 for a software I wouldn't use every day was still holding me off. Fortunately, upon my request the guys from SyncRO Soft were so kind to grant me a discount of 50%. So far, I haven't had the time to discover all the features Oxygen has. However, what I definitely can say is that the developers put a hell of an effort into providing an intuitive and good working xml development environment which I can only recommend.