[linux-l] Plan9-Konzepte (was: VCS)

[Volker Grabsch]

On Thu, Apr 20, 2006 at 11:48:50PM +0200, Steffen Dettmer wrote:
> > > und ausserdem will ich keinen Webserver mit einem völlig ungeignetem
> > > Protokoll in so einem System haben. Hab das nie verstanden, wozu man
> > > das brauchen soll. Weil es über Proxies geht? Muss man halt SOCKS
> > > nehmen. Oder CGI-Irgendwas, was nicht für Menschen, sondern für
> > > Tools ist. Wozu? Damit der Client auf'm Mobiltelefon läuft?
> > 
> > So ungefähr arbeitet Darcs. Ja, CGI-Scripte sind meist besser. Ein
> > Apache-Modul ist performanter.
> > 
> > Mercurial bringt seinen eigenen Server mit, das halte ich für
> > problematisch. Effizientes Protokoll (irgendwie aber auch HTTP,
> > AFAIK), jedoch schlecht in andere Strukturen integrierbar.
> 
> Wieso, Unix lebt seit Jahren nur mit Files, ging auch ohne HTTP prima,
> und Plan9 abstrahiert weiter von Files (nicht von XML Sprachen) - soo
> falsch kann das Konzept wohl nicht sein, oder?

Da stimme ich dir vollkommen zu, was das allgemeine "übertragen" von
Daten angeht. Was jedoch die Ansteuerung von Diensten angeht, da geht
Plan9 IMHO noch nicht weit genug.

Dass der Datenstrom nur eine Datei ist, ist schonmal super. Kein TCP/IP
und 'zig andere Protokolle in Client-Anwendungen, sondern alle Kommunikation
im Unix-Domain-Socket-Stil. Ich wäre der letzte, der irgendwas dagegen
hätte.

Aber ich finde, sie hätten nicht nur den *Zugriff* auf den Datenstrom,
sondern auch dessen *Form* standardisieren sollen. Momentan heißt es
einfach nur "Byte-stream". Sicher, einige wenige alte oder
geschwindigkeitskritische Anwendungen brauchen das. Oder auch die
Kommunikation zur Hardware (leider).

Aber was die Anwendungen angeht, die kommunizieren doch sowieso
zeilenweise. Wäre da nicht zumindest eine reine zeilenbasierte API
besser? Das abstrahiert auch gleich von den Zeilenenden weg. (Gewisse
Zeichen wie 000, 012, 015 zu verbieten ist nur selten eine
Einschränkung, meist sogar willkommen. Oder man verbietet sie nicht,
sondern konvertiert sie intern)

Auf diese Weise könnten Programme schonmal nicht nur byteweise,
sondern in String-Blöcken kommunizieren. Sicher, im Netzwerk-Fall
würde man das entsprechend auf einen klassischen Textdatei-Bytestream
zurückführen. Aber laufen die Programme im selben Rechner, könnte man
die Strings einfach 1:1 weiterleiten, das wäre also sogar effizienter.

Ach ja, und diese Strings sind natürlich alles "Unicode"-Objekte. Also
encoding/decoding gleich mit wegabstrahiert. Okay, dieser Vorteil wäre
nicht soo riesig, weil man in den Bytestreams ohnehin schon UTF-8
vorschreibt, aber immerhin.

Selbiges für strukturierte Daten. Egal, ob intern nun JSON oder XML
genommen wird, auf jeden Fall sollten sich Applikationen direkt mit
solchen Datenstrukturen unterhalten können (im begrenzten Rahmen, z.B.
nur verschachtelte Listen von Strings).

Würde das Betriebssystem diese Dinge ebenfalls direkt unterstützen,
würde das die Applikationen noch weiter entlasten, und dennoch allen
Traffic menschenlesbar machen. Das eine Programm kann z.B. nur Byte-
Streams sichtbar machen, gut, sehe ich JSON-Code. Immerhin besser,
als bei jeder Anwendung eine andere Text-codierung von strukturierten
Daten (mal als Tabelle, mal eingerückt, mal mit Klammern, ...).
Ein anderes Programm unterstützt vielleicht die Strukturen, und kann
sie mir als auf/zu-klappbare Liste ("Outline") anzeigen.
(oder als Tabelle, oder worauf immer man steht)


Alternativ könnte man natürlich auch erlauben, in einem Stream
mehrere "Dateien/Verzeichnisse" zu übertragen, aber ob dieser Ansatz
für Protokolle im Frage/Antwort Stil wirklich so geeignet ist, weiß
ich nicht.


Was ich mit unterschiedlichen Text-Formaten für die gleichartige
Strukturen meinte, sieht man sehr schön, wenn man z.B. die Ausgaben von

    cat /proc/cpuinfo
    cat /proc/version
    cat /proc/pci

vergleicht. Das erste ist "Formular"-Stil. Das zweite ist eine
Leerzeichenseparierte, Klammer-verschachtelte Liste. Das dritte
ist im YAML/Python-Stil eingerückt. Ganz zu schweigen von
Konfigurationsdateien.

Soweit ich gesehen habe, findet man entsprechende Beispiele genauso
auch in Plan9.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR