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 <http://en.wikipedia.org/wiki/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 GPLReferenzimplementierung.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.
<<attachment: Bernhard_Fastenrath_2.vcf>>
_______________________________________________ fsfe-de mailing list fsfe-de@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/fsfe-de
