Zuallererst die Frage: Was meine ich mit „aufgeben“?
„Aufgeben“ im Sinne von engl. „to abandon“ oder „aufgeben“ im Sinne von engl. „to hand in“?
Nun gut, diese Frage möchte ich bewußt offenlassen.
Aber was ist „es“?
„Es“ ist in erster Linie eine Reihe von Ideen, die alle im Laufe der Zeit entstanden sind, und die alle mehr oder weniger veröffentlicht worden sind (jeweils auf einem meiner 5 Blogs oder in einem meiner beiden Sourceforge Projekte).
Warum ich diese Ideen alle veröffentlicht habe und nicht für mich behalte, liegt letzten Endes daran, dass ich für mich persönlich keine Chance gesehen habe, damit Geld zu verdienen, dass mein jeweiliger Arbeitgeber daran nicht interessiert war, und dass ich dann letzten Endes aus einem schlechten Gewissen gegenüber der Menschheit mir immer die Arbeit angetan habe, es zu veröffentlichen.
Ein gewisser Exhibitionismus mag auch dazu beigetragen haben.
Und die Tatsache, dass eine Veröffentlichung letzten Endes der einzige Beweis dafür ist, dass ich diese Idee gehabt habe (als erster oder nicht, ist hier nebensächlich).
Das meiste davon ist nicht neu, aber es ergibt in Summe einen ganz schönen Überblick darüber, was dabei zwangsläufig herauskommen muß, wenn sich ein Mensch aus der Sparte Telekom in seiner Freizeit mit den Möglichkeiten von 3D-Graphik beschäftigt, insbesondere mit Web3D Technologien, insbesondere mit dem Netzwerksensor-Interface.
A) Der persönliche Urknall
Noch bevor ich wußte, was Google Earth ist, war da eine „Inspiration“, die im Wesentlichen auf dasselbe hinausläuft.
Bloß, dass ich von Anfang an von einer verteilten Datenbank geträumt habe, die Server in aller Welt (und von verschiedenen Eigentümern) durch ein Internetprotokoll miteinander verbindet und 3D-Szenen aufgrund eines primary Key zusammensetzt, den ich als „VRA“ (Virtual Roaming Area) bezeichnet habe – ein geschlossenes oder offenes Polygon.
Ich habe das als DIGITS bezeichnet („Distributed Internet Geographic Information Transmission Service“).
Ich nehme an, zur Entwicklung dieser Sache hat man meine Ideen nicht gebraucht, dennoch habe ich sie sicherheitshalber als Unterverzeichnis im Source Code meines ersten Open Source Projektes veröffentlicht: http://simulrr.sourceforge.net
B) Eisenbahn-Simulation
Kann man Web3D verwenden um Eisenbahnen zu simulieren?
Natürlich!
Es gab auch bereits einige nette Beispiele im Web, dennoch fehlte mir noch der Multiuser-Mode.
Ich fragte auf der X3D-public Mailing Liste, ob es hier bereits standardisierte Lösungen für den Multiuser-Mode gab.
Ja, sagte man mir, einerseits gab es da die DIS Komponente (Distributed Interactive Simulation), die bereits fertig standardisiert war – jedoch nur von einem Web3D Browser unterstützt -, andererseits gab es den Netzwerksensor, welcher ein sehr viel generelleres Interface darstellte, aber es gab immerhin zwei Web3D Browser, mit denen man Versuche anstellen konnte.
Ich entschied mich für den Netzwerksensor, obwohl natürlich die Verwendung eines generellen Interfaces für komplizierte Anwendungen (also z.B. für eine Eisenbahn-Simulation) prinzipiell höhere Aufwände bedeutet.
Im Gegenzug war man nicht von einem einzigen Browserhersteller abhängig (theoretisch, zumindest) und man konnte die Funktion des Interfaces auf die eigenen Wünsche „hinbiegen“.
Diese Idee verfolgte ich auf dem Blog http://simulrr.wordpress.com
und im Sourceforge Projekt http://simulrr.sourceforge.net
C) Simple Multiuser Szenen
Idee B) führte dazu, dass ich begann, einen Satz von X3D Prototypen experimentell zu entwickeln. Ich bezeichnete diese Prototypen als „SRR Framework“, wobei der Begriff „Framework“ eher das bezeichnete, was einmal daraus werden sollte, als das, was es tatsächlich schon war.
Da das „SRR Framework“ mittlerweile recht komplex geworden war, beschloss ich, es in einen Basisanteil (das sogenannte „base module“) und spezifische Anteile (sogenannte „extension modules“) zu zerlegen. So könnte der Basisanteil für beliebige „Simple Multiuser Online Scenes“ (SMUOS) und die spezifischen Anteile für verschiedene Anwendungen (Eisenbahnsimulation, Autosimulation, Flugzeugsimulation, Bürozusammenarbeit (Collaboration), etc.) verwendet werden.
Aufgrund mehrerer Ursachen bildete sich daraus
D) Die Idee SMUOS/C3P
Das „Base Module“ des „SRR Frameworks“ läßt sich bereits jetzt für einfache Multiuser-Szenen benützen, hat aber aus Sicht eines Mitarbeiters der Telekom Branche den entscheidenden Nachteil, dass für die Kommunikation mit dem Collaboration Server ein proprietäres Protokoll verwendet wird.
Dieses Protokoll sollte man also definieren.
Weiters wäre es im Sinne einer Standardisierung sinnvoll, das „Base Module“ des „SRR Frameworks“ „tieferzulegen“, also eine X3D Komponente zu definieren, welche im Wesentlichen die API bietet, die im SRR Framework experimentell entwickelt worden ist.
Diese Idee SMUOS/C3P beschreibe ich auf dem Blog http://smuos.wordpress.com
und im (ungestarteten) Sourceforge Projekt http://smuos.sourceforge.net
Ein weiterer Aspekt – der auf eine Mail auf der X3D-public zurückgeht und von dort „inspiriert“ war – ist die Idee, die „Wirklichkeit“ als (N+1)-te Szeneninstanz in die Multiuser-Session einzubinden.
Diese Idee ist in einem Paper zusammengefasst, welches ich am 1.März 2011 veröffentlicht und zuletzt am 18.Jänner 2012 geändert habe. Dieses Paper findet sich unter anderem hier: http://smuos.wordpress.com/2011/03/01/smuos-and-the-ietf/.
So, das war „es“.
Jetzt liegt es an Dir, lieber Leser, zu entscheiden, ob ich mit „aufgeben“ „to abandon“ gemeint habe, oder „to hand in“.
Oder, ein bisschen direkter formuliert, sozusagen mit den Worten der letzten Hornbach-Werbung: „Und jetzt Du.“
Meint
Euer Christoph
Veröffentlicht von Yeti 
Christophs Blog 