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

[Volker Grabsch]

On Tue, Apr 25, 2006 at 02:37:48AM +0200, Steffen Dettmer wrote:
> > Auf diese Weise könnten Programme schonmal nicht nur byteweise,
> > sondern in String-Blöcken kommunizieren. 
> 
> Dann doch gleich Nachrichten definieren, sind flexibler, aber gibt's
> schon, ist aber ne Ebene über Byte-Strömen.

Achso? Das gibt es schon was einheitliches? Wie heißt das denn?

Vielleicht meinst du mit Nachrichten ja das gleich wie ich mit meinen
Beispielen.

> > Programme im selben Rechner, könnte man die Strings einfach 1:1
> > weiterleiten, das wäre also sogar effizienter.
> 
> Effizienter als ein memcpy für'n Bytebuffer?

Nein, Effizienter als er Umweg über Bytebuffer.

Momentan: Applikation A und B haben eine gemeinsame Datenstruktur,
und kommunizieren.

Aktueller Vorgang:
    * Serialisierung der Datenstruktur
    * Memcopy
    * Parsen

Mein Vorschlag:
    * Memcopy der Datenstruktur

> > 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).
> 
> XML? Das super-redundante, angeblich menschenlesbare Zeugs da? Bis auf
> ohnehin langsame Java-Anwendungen benutzt man doch sowas nicht, oder?

Naja, nicht so überheblich. Jede Erfindung hat ihre Berechtigung. XML
wird viel missbraucht, insbesondere für einfache Datenstrukturen (da
reiht sich das Java-Zeug mit ein). Aber für alles, was Text mit Markup
ist, kann man XML recht gut gebrauchen, und würde sich mit Plaintext
oder JSON das Leben unnötig schwer machen.

Deshalb habe ich ja auch JSON zuerst genannt. :-)
Kennst du ein besseres, menschenlesbares, generisches Datenstruktur-
beschreibungsformat, dann her damit. Außer YAML oder in begrenztem
Rahmen CSV (bzw. leerzeichensepariert) kenn ich da nichts.

> >     cat /proc/cpuinfo
> >     cat /proc/version
> >     cat /proc/pci
> 
> OK, schönes Beispiel! Aber nicht gerade Schnittstellen zwischen
> verschiedenen Applikationen, oder? Ich mein, man ruft ja gethostbyname
> auf und sendet keine XML Nachricht an /proc/get/host/by_name oder so.

Mag sein, aber es ist doch ein Unterschied, ob ich nur wissen brauche,
was dort steht:
    Liste von Feldern mit Einträgen processor, vendor_id, ...

oder ob ich genau wissen muss:
    mehrzeilig
    Jede Zeile der Form "processor", viele Leerzeichen, Doppelpunkt,
        Prozessortyp.
    ...

Das macht doch die Applikationen unnötig komplex. Im Prinzip reicht es
doch, wenn sie die Datenstuktur kennen. Wieso müssen sich die
Applikationen außerdem mit den Feinheiten der Serialisierung
auseinandersetzen? Wieso braucht man für jede dieser Schnittstellen
einen eigenen Parser?

Und was "gethostbyname"... angeht: Klar sind das nette Funktionen,
die man auch verwendet, aber nicht für alles. Du kannst doch nicht
für jeden Eintrag in /proc einen neuen System-Call einführen, der
Sinn und Zweck dieser "auch von menschen lesbaren" Formate ist doch,
dass man darauf eben nicht angewiesen ist.


Viele Grüße,

    Volker

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