| |
 |
Veröffentlicht durch Momo_102 am Mittwoch 27. Februar, 02:01
Aus der microsoft-patented-transfer-protocol Abteilung
|
|
|
|
|
egal schreibt "Bin grad auf meinem More Over Stream über diesen Kommentar von Don Box gestolpert. Der Liebe, schlägt doch glatt vor HTTP zu ersetzen. Keine so schlechte Idee, eigentlich, aber wäre das nicht eher eine Symptombekämpfung als eine Systemverbesserung?
|
|
|
|
|
|
|
Sponsorn sollen das dann IBM und Microsoft und am besten die ganze Industrie, wird es dann ein IMTP (IBM Microsoft Transfer Protocol) geben? Ein entsprechendes RFC habe ich grad nicht gefunden, und ehrlich gesagt, ich wäre froh über eine Evolution im Daten Transfer Protokol. Aber irgendwo drückt mich der Kosten-Nutzen Schuh. Andererseits, hey, das wird den Markt beleben, Millionen von HTTP-Server wollen ersetzt werden... Y2K die zweite?"
|
|
|
|
< Opera 6 Beta 1 für Linux | Druckausgabe | Heise, mal heiser! > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
|
|
Mr. Box schreibt hier, dass HTTP für diese und jene Applikationen nicht geeignet ist, und dass man daher HTTP allgemein weniger benutzen soll. Statt dessen schwebt ihm offensichtlich (zwischen den Zeilen) ein eierlegendes Wollmilchprotokoll vor.
Das ist wieder mal typisches Schreibtischdenken. Der Ansatz ist nicht neu, und wurde bekanntlich auch schon von der ISO, welche eine viel höhere Akzeptanz geniesst als Microsoft und IBM, erfolglos versucht.
Woran solche Ansätze regelmässig scheitern: Die Entwickler wollen das Protokoll nehmen, dass für ihre Aufgabe am besten geeignet ist. Und den Anwendern ist das Protokoll völlig egal, solange die Applikation darüber einwandfrei funktioniert. Anscheinend versucht man nun FUD-Taktiken gegen HTTP anzuwenden, um so die Entwickler für sich zu gewinnen. Ein schönes Beispiel sind die erwähnten P2P-Applikationen (Usenet, IRC, Gnutella, Freenet...), die laut Mr. Box nur mit Tricks über HTTP zu realisieren sind. Da hat er recht. Darum wird es auch nicht gemacht. Jedenfalls ist mir keine bekannt.
Einen Nachteil hat HTTP allerdings: Als verbindungsloses Protokoll ist es eigentlich nicht für Session-basiertes Arbeiten (z.B. mit einer Webapplikation) geeignet. Aber es geht. Und der Trick mit den Session-IDs ist nicht so schmutzig, wie er immer wieder gemacht wird.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Don Box ist IIRC der Clown, der es besonders witzig fand einen Artikel über SOAP in einer mit Schaum gefüllten Badewanne zu halten. Jemand hat hier ein einem Artikel über die Präsentatin der MS Student Community an der ETH darüber berichtet (finde gerade den Link nicht, vielleicht kann den jemand von Symlink ergänzen :-)).
Klar ist jedenfalls warum Don Box ein neues Protokoll möchte. Immerhin ist er Mitarbeiter von Microsoft und .NET Spezialist und Autor. Und Microsoft käme natürlich für die ganze .NET Geschichte ein neues, möglichst proprietäres Protokoll gerade richtig.
Der Trick mit den Session-IDs ist auch aus meiner Sicht problemlos. Immerhin bieten moderne applikationsserver dafür APIs die das transparent handeln - jedenfalls die die ich kenne (J2EE und Coldfusion).
|
|
|
|
|
|
|
|
|
|
|
|
|
Alles was Donny fordert ließe sich problemlos über zusätliche HTTP-Header realisieren... Sprich ein RFC zu HTTP/1.2 würde genügen...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 27. February, 11:59 MES (#4)
|
|
|
|
|
Das ist wieder mal ein mustergueltiger Artikel, den da Mr. Box absondert. Vordergruendig macht er sich einfach laecherlich, indem er aussagt, dass HTTP nicht geeignet ist fuer Anwendungen, fuer die es eh' nicht vorgesehen ist. Die Information zwischen den Zeilen ist halt wieder mal interessanter: .NET wird laengerfristig ein neues Protokoll bringen (ueberrascht das wen? Ich dachte, es unterstuetzt sowieso ein paar Protokolle, u.a. XML-RPC), der Standard ist ungenuegend (aha, deshalb also muss HTTP herhalten!), deshalb wird irgendeine Firma (Microsoft, wer denn sonst) ein neues, ueberlegenes, proprietaeres Protokoll einfuehren - und dieses Protokoll soll dann natuerlich nebenbei noch HTTP ersetzen - schliesslich kann man als Firma ja keine Lizenzgebuehren fuer HTTP verlangen, nicht?
Hab' ich recht?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Naja, und Microsoft war ja schon immer gut dabei, sinnvolle, offene Protokolle zu definieren.
Man muss nur schauen, wie universell und nahtlos sich die MS-Protokolle (Protikoll-Implementationen) in heterogene Umgebungen einbinden lassen. Bas beweist doch, dass MS geradezu praedestiniert ist, neue, universell einsetzbare und allgemein akzeptierte Protokolle zu definieren. :-)
--
auch die Zehe ist ein Laufwerk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Lol... Erst wird SOAP erfunden um abzusahen (Orginalzitat IBM) ob wohl bereits genügend zuverlässige RPC-Mechanismen wie CORBA existieren... und dann stellt man fest, daß es eigentlich doch 'ne Scheißidee war Any-Purpose-RPC über HTTP zu machen... Einfach köstlich... Und wenn ich dran denke wie wir den IBM-Menschen, der uns an der HUB SOAP verkaufen wollte auslachten... nee... Ein Schelm, wer hinter all diesem "SOAP rulez", "HTTP sux" böses ahnt...
<Conspiration>So wird es also wirklich darauf hinauslaufen, daß das Internet in ein riesiges von Microsoft dominiertes MickeyNet und ein winziges auf offenen Standards basierendes Netz zerfällt... Was soll's: Gehen wir halt alle mit unseren rebellischen Ideen um ein offenes, unabhängiges, zensurfreies Netzwerk in den Untergrund. Bleiben uns wenigstens all die Lizenz/Patent-Scherereien erspart, wenn wir nicht am MickeyNet teilnehmen... Vielleicht bleibt ja gar ein Schlupfloch, mit dem das MickeyNet getunnelt werden kann, um freie Daten zu transportieren...</Conspiration>
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 03. March, 16:31 MES (#11)
|
|
|
|
|
Jep XML-RPC ist .NET tauglich, bin grad selbst dabei einbischen damit zu spielen. Bezueglich propritaeres Protokoll, nun, ich denke nicht das Microsoft das vorhat, wie Don ja sagte, das ist nie durchzusetzen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 27. February, 14:24 MES (#5)
|
|
|
|
|
Also ich kann mir ein Ersetzen von html nur unter
dem Aspekt vorstellen, dass sich vernünftige Verbesserungen nicht ohne Inkompatibilitäten zu erzeugen umsetzen lassen. Ich sehe allerdings bislang kein Problem, inkompatibel zu werden, wenn man mal html ein bisschen nachbessert. Nötig ist es aber schon.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 27. February, 15:06 MES (#7)
|
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 28. February, 02:53 MES (#10)
|
|
|
|
|
Das ist alles. M$ versucht hier, offene Protokolle zu torpedieren. Zur Erinnung: Das W3C erlaubt jetzt teilweise patentgeschützte Protokolle. Wäre ja schade, wenn man das nicht ausnützen würde, oder?
|
|
|
|
|
|
