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

[Steffen Dettmer]

* Volker Grabsch wrote on Sun, Apr 23, 2006 at 21:26 +0200:
> Ich würde es mir ziemlich cool vorstellen, wenn man ähnlich einem
> TCP/IP - Paketsniffer sich zwischen Prozesse hängen könnte,

strace!

> Würde man dann nicht nur irgendwelchen Plaintext sehen, sondern
> richtige Pakete von Datenstrukturen, die man sich anzeigen lassen
> kann, aufklappen, etc., *das* wär doch was.  

gdb?

> Momentan müsste ein Programm alle gängigen Protokolle verstehen, um
> das zu bewerkstelligen.

Ja logisch, wenn Du ein X.509 Zertifikat als XML ausgibts, denkt man
zwar, man verstünde es (als Mensch), aber so wirklich dann noch nicht.
Oder welche Zeichen genau sind in Email erlaubt? :-)

> XML muss ja auch nicht sein. Aber Richtlinien, wie man strukturierte
> Daten in Streams überträgt, wären nicht übel. 

ASN.1?

> Sowas kann man gar nicht weit genug unten festlegen.

Man muss es oben festlegen, weil man nur da genau genug weiss, was man
an Daten haben wird. Woher soll ein Kernel/OS wissen, dass ich ein
Datenelement Schuhgrösse und "linke Schuhgrösse" aber kein "rechte
Schuhgrösse" habe?

> Sehe ich nicht so. Wenn das jede Applikation für sich macht, ist das
> viel mehr "bloat".

Stimmt nicht!

Wir haben ASN.1 Module, die werden in ein "paar Zeilen C" kompliliert.
Dann haben wir auch XML-Dateien, die werden von einem Xerces-C
verarbeitet. Das Xerces-C ist dann sowas um die 7 MB an Sourcen oder so.
Absoluter Overkill jedenfalls.

> Sicher kann man darüber streiten, ob eine Stringlisten- bzw.
> Zeilen-basierte API nun zum Kern gehört oder nicht. Falls nicht, wäre
> es auf jeden Fall eine wunderbare Library.

Braucht man doch aber nur für User, und da hat Unix doch die line
discipline, oder?

> Genauso eben eine API für die Übertragung von strukturierten Daten.

Wie sollte denn die nur Aussehen? Mach doch mal ein Pseudocode-Beispiel,
dass meine Katze übertragen kann.

> Die ganzen Objekt-Streaming-Geschichten der OO-Sprachen könnten
> dann wahlweise auf den Bytestream oder schon auf besagter anderer
> API aufsetzen. 

DER und sogar XML sind am Ende Streams - braucht man doch also gar
nicht?

Ich dachte, es wäre ein Durchbruch, überall binary-safe channels zu
haben...

> Letzteres hätte den Vorteil, dass es sich als
> Programmiersprachen-unabhängiger Standard entwickeln könnte. Also wie
> Corba, nur halt auf Verschachtelte Listen von Strings begrenzt.

Was bitte willste denn damit?! Das ist doch nichtmal typsicher?

> (d.h.  Corba ohne "bloat") ... also im Prinzip wie XML-RPC, nur eben
> ohne "bloat" von XML und HTTP.  ;-)

(CORBA ist übrigens erstaunlich effizient. Und ziemlich genial, finde
ich).

> Naja, und will man noch etwas mehr Geschwindigkeit rauskitzeln,
> und gleichzeitig Server & Client entlasten, nimmt man eben kein
> XML, sondern JSON als Format für diese Daten.

Und will man noch etwas mehr, nimmt man C/C++, oder? :-)

> Plan9 hätte dann eine sehr leichtgewichtige Variante davon, ähnlich
> ihrem Filesystem-Protokoll. Damit kann man dann Kisten direkt verbinden,
> einfach und schnell, oder über entsprechende Dienste der Umweg über
> XML-RPC, SOAP, Corba, etc. ... jede stinknormale Plan9-Anwendung wäre
> mithilfe dieser "Treiber" (oder Dienste) auch über XML-RPC, SOAP, etc.
> ansprechbar, falls man es braucht.

Mach doch bitte mal ein Beispiel.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.