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

So Apr 23 21:26:40 CEST 2006

On Sun, Apr 23, 2006 at 10:16:43PM +0200, Nico Golde wrote:
> > 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.
> 
> Es ist bei Plan9 wohl so, dass es ein Interface gibt 9P und 
> UTF-8 streams. P9 ist im Prinzip ein fetter Buffer, der 
> übers Netzwerk erreichbar ist. Wie da letztendlich drauf 
> zugegriffen wird, zeilen oder byteweise bleibt dem Programm 
> überlassen. einen wirklichen Vorteil von der 
> Zeilenverarbeitung sehe ich auch nicht. Das hat mit Plan9 
> erstmal wohl nichts zu tun, wenn du ein Programm für 9P 
> schriebst, kannst du es auch anders machen.

Ja eben, jeder kann es anders machen. Ähnliche Probleme werden
individuell gelöst. Dieselbe Grundidee, die zur konsequenten Nutzung
von Dateisystem-APIs statt vieler spezial-APIs führt, legt doch
nahe, dass man auch Kommunikation über Streams an gemeinsame APIs
bindet, statt für jede Applikation ein Byte-für-Byte selbstentwickeltes
Protokoll zu haben.

Ich würde es mir ziemlich cool vorstellen, wenn man ähnlich einem
TCP/IP - Paketsniffer sich zwischen Prozesse hängen könnte, und ihre
Kommunikation beobachtet. 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.
Momentan müsste ein Programm alle gängigen Protokolle verstehen, um
das zu bewerkstelligen.

Ein ganz anderer Weg wäre natürlich, z.B. über das Anlegen neuer
Unterverzeichnisse in einem gemeinsam genutzten Verzeichnis zwei
Prozesse kommunizieren zu lassen. Der Inhalt der Unterverzeichnisse
würde dann die strukturierten Daten widerspiegeln. Aber das wird
nicht gemacht, und ich fände es auch irgendwie komisch, wenn ein
IRC-Client während seiner Kommunikation mit einem IRC-Server ständig
Verzeichnisse anlegt. Es wäre von den API-Aufrufen her auch sehr
umständlich, das Filesystem-Protokoll ist für diese Art von
Kommunikation einfach nicht geeignet.

(sondern eher für sowas wie das Festlegen der Hintergrundfarbe des
WindowManagers durch bearbeiten einer kleinen Datei)

Ich weiß, das ganze geht sehr stark in die Richtung der Kommunikation,
die innerhalb von KDE und Gnome vonstatten geht. Auch dort implementiert
man ja virtuelle Dateisysteme und ähnliches. Zum Teil ist das Krempel,
den man unter Plan9 von Hause aus geschenkt bekäme, aber zum Teil sind
da sicher Dinge dabei, die man auch in Plan9 noch von Hand stricken
müsste.

> > Ach ja, und diese Strings sind natürlich alles "Unicode"-Objekte. 
> 
> Objekte?

Ich weiß nicht, wie man das in C handhabt. Gibt es spezielle strlen(),
... Funktionen für UTF-8 codierte char* ?

Oder gibt es sowas wie "wchar" unter Windows (also 16-bit-Zeichen) und
man nimmt UTF-16?

Wie dem auch sei, in OO-Sprachen wie Python, Java, und etlichen C++
Bibliotheken ist es jedenfalls üblich, dass es Unicode-Objekte gibt.
Das sind im Prinzip String-Objekte (in Java heißen sie sogar "String"),
die aber eben den gesamten Unicode-Zeichensatz unterstützen. An deren
interne Darstellung kommt man von außen nicht ran (ist meist UTF-16),
und wenn man diese Unicode/String-Objekte serialisieren will (d.h. in
einen Byte-Stream schreiben will), muss man halt ein Encoding angeben.
Default ist normalerweise UTF-8.

Ich dachte mir, wenn's ein entsprechendes Interface gibt, dann sollte
man damit ganze Strings transportieren können, sodass die Applikationen
sich nicht beim Lesen mit halben UTF-8-Zeichen (2-byte-Zeichen, von
denen bisher nur 1 byte übertragen ist), etc. herumschlagen müssen.

> > 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).
> 
> Das könnten sie auch, 9p lässt da Spielraum.
> Warum das so nicht gemacht ist, ist ne gute Frage. Ich 
> schätze mal, weil der Großtiel von Plan9 in Ken 
> Thompson-Style C geschrieben ist und C-Programmierer sich 
> auch eher weniger mit sowas wie XML rumschlagen.

XML muss ja auch nicht sein. Aber Richtlinien, wie man strukturierte
Daten in Streams überträgt, wären nicht übel. Sowas kann man gar nicht
weit genug unten festlegen.

> > Würde das Betriebssystem diese Dinge ebenfalls direkt unterstützen,
> > würde das die Applikationen noch weiter entlasten, und dennoch allen
> > Traffic menschenlesbar machen. 
> 
> Aber auch den Code bloaten :)

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

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.

Genauso eben eine API für die Übertragung von strukturierten
Daten. Die entsprechende Library könnte intern JSON oder irgendwas
anderes nehmen, man muss sich halt nur darauf einigen.

Die ganzen Objekt-Streaming-Geschichten der OO-Sprachen könnten
dann wahlweise auf den Bytestream oder schon auf besagter anderer
API aufsetzen. 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.
(d.h. Corba ohne "bloat") ... also im Prinzip wie XML-RPC, nur
eben ohne "bloat" von XML und HTTP.  ;-)

> > Das eine Programm kann z.B. nur Byte-
> > Streams sichtbar machen, gut, sehe ich JSON-Code.
> 
> Ich kenne JSON nur vom Namen und Funktion, habs nie 
> bentutzt.

JSON ist im Prinzip ne verschachtelte Array/Hash-Struktur, die
syntaktisch gültiges JavaScript (und nebenbei auch gültiges Python)
ist.

Wird im Web gerne als XML-Alternative genommen. Du hast z.B. auf dem
Client (Browser) etwas JavaScript am laufen, das von einer URL
wie ".../inhalt.xml.php" den Inhalt einer Seite holt, als eigenes
XML, und daraus dann HTML bastelt. Das entlastet den Server. Quasi
ein Client-seitiger Stylesheet.

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.

> > 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)
> 
> Ich glaub du vergisst einfach, dass Plan9 schon ewig alt 
> (älter als die von dir angesprochenen Erfindungen ist). Das 
> gilt wohl für die meisten modernen Betriebssysteme.

Das ist gut möglich. Aber die Kritik ist unabhängig von den bisherigen
Technologien. Wenn der von mir angesprochene Punkt nämlich schon im
Kern eines Plan9-Systems eingebaut wäre, würde es mit einem Schlag von
XML-RPC, SOAP, und wie sie alle heißen, wegabstrahieren. Diese Dinger,
die man heutzutage noch "Technologie" nennt, würde man aus Plan9-Sicht
dann bestenfalls "trivial" nennen. IMHO.

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.

Viele Grüße,

    Volker

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