Alle guten drafts sind 3, also hier noch ein Vorschlag: Das Amiga
Filesystem verwendet doch intern
messages. Man wäre also recht schnell bei einem network
filesystem, wenn man für das
bestehende Amiga (oder AROS, mit einigen Änderungen) Filesystem
Interface ein Wire Format
spezifiziert. Nichts gegen CIFS oder NFS, aber ich muss doch kein
AROS filesystem in NFS
einpacken, wenn ich auf der andere Seite wohlmöglich wieder das
AROS filesystem interface
benutzen möchte. Das 'R' in AROS steht ja auch für Reseach, daher
könnte man hier durchaus
ein wenig forschen, auch wenn man vermutlich ähnliche Ideen wie in
NFS und CIFS schon
existieren herleiten wird.
Bernhard Fastenrath wrote:
Ich habe irgendwann um 1998 mal ein kommerzielles Produkt
gesehen, dass war so eine Art Wiki, nur
komplizierter und mit stabilen, bidirektionalen Links. Man
könnte auch ein Standard für stabile
bidirektionale Links zwischen Wiki Seitenfragmenten
spezifizieren. Dann könnte also in der Wikipedia
jemand die Information hinterlegen, dass sein Wiki auf eine
Überschrift einer Seite verlinkt und Wikipedia
könnte einem Editor mitteilen, dass eine Überschrift nicht
gelöscht werden sollte, oder ihre Aufgabe
sinngemäß einer anderen Überschrift übertragen werden sollte,
damit der "incoming Link" nicht
ins Leere geht. Das könnte man auch als IETF draft einreichen.
Das hätte insbesondere den Vorteil,
dass verschiedene Wikis und Nicht-Wikis ein einheitliches
Protokoll für diesen Zweck hätten.
Bernhard Fastenrath wrote:
Ich suche Koautoren für einen IETF draft. Das Portnummern
Mapping über /etc/services ist mir zu simpel.
Ich würde gerne etwas wie ONC RPC portmap bzw.
der Java Registry spezifizieren, aber allgemeiner
und nicht nur für RPC oder RMI. Natürlich sollte das Ergebnis
ein offener Standard sein mit einer GPL
Referenzimplementierung.
Zu addressieren wären evtl.: Zugriffsrechte, SSL/TLS,
tunneling/forwarding, VPN, load balancing,
filtering, namespaces, versioning, message queues (z.B. siehe
OS/2 ?), RPC, RMI, failover und monitoring.
Zugriffsrechte könnten beispielsweise einen Dienst sperren bis
dieser über die allgemeine Zugriffskontrolle
für den Anrufer freigeschaltet wird. Also auch eine SSH würde
nicht antworten, als wäre sie hinter einer
Firewall, bis man den Dienst freischaltet. Okay, man könnte dann
gleich ein VPN verwenden, aber vielleicht
gibt es ja auch Nachfrage für eine weniger aufwendige, wenn auch
weniger sichere Lösung.