Das 3D-Internet saugt das 2D-Internet in sich auf

finally it is done! Linden Lab hat mit dem seit gestern zur Verfügung stehenden neuen Second Life Viewer 2 Beta ein Feature implementiert, dass wir seit längerem vermissen und deren Entwicklung seit 2007 verfolgen. Das Stichwort heißt “HMTL on Prim” oder “Media on a Prim” bzw. “Browser on a Prim”. Zuletzt berichteten wir von der NaviDemo, die dies eindrucksvoll zeigt.

Mit diesem lang ersehnten Feature wird das 2D-Internet, das sogenannte FlatNet buchstäblich in das 3D-Internet aufgesaugt, wie Phil Rosedale es einmal gesagt haben soll.


Mit diesem neuen Meilenstein in der Entwicklung von Second Life ist es jetzt tatsächlich möglich, vollwertige 2D-Webanwendungen zu integrieren und zu teilen. Es ist so, als ob sich mehrere Benutzer gleichzeitig ein Browserfenster teilen!



Die Anwendungsvielfalt ist schier unglaublich. Zum Einen können wir unseren eigenen Bildschirm live ins Netz streamen und für Schulungen zurück in Second Life übertragen, indem wir einfach einen Browser mit dem Stream in Second Life öffnen. Das wäre aber nur Selbstzweck. Wir können nun aber auch jede webbasierte Anwendung in Second Life teilen und schulen!

Ich bin der festen Überzeugung, dass dies ein wichtiger Meilenstein in der Entwicklung und Akzeptanz von Second Life ist.

Das sogenannte Flachland bzw. FlatNet wird nun endlich in die Dreidimensionalität, im 3D-Internet integriert. Hierzu ein kleines Video:



Über Andreas Mertens

Andreas Mertens aka Patrick Wunderland (SL) ist Initiator von avameo und schreibt seit 2006 für diesen Blog.

Kommentare

  1. Kai Ludwig says:

    “finally it is done!” – Frei übersetzt: “Endlich sind die Schnarchnasen mal wenigstens mit irgendwas wieder aus dem Quark gekommen.”

    Drei Jahre für die Einbindung einer fertigen Bibliothek, nebenbei etwas GUI-Kosmetik, und zwei neue Funktionstexturen für den Avatar. Das wars bzgl. der neuen Version.

    Das nenne ich allerdings eine Leistung und hier findet die eigentliche und meist verkannte Bedeutung des Begriffes “Quantensprung” endlich mal ein schönes Beispiel.

    Natürlich ist es schön, dass Linden Lab endlich mal wieder etwas am Viewer getan hat und mit dem Thema “Shared Media” kann man auch mit Sicherheit eine Menge anfangen. Das stelle ich auch gar nicht in Frage.

    Aber man sollte die dahinterstehende Entwicklungsleistung doch eher korrekt als mickrig und total überbewertet einschätzen. Ein bezahlter C++ Programmierer erledigt das aber mal locker in < 1 Personenmonat.

    Schön ist es aber trotzdem. Da ja der Viewer auch in der Version 2.0 immer noch Open Source ist (sein muss, weil er ja aus dem GPL-Lizensierten 1.x Viewer hervorgegangen ist), kommt die Entwicklung mit Sicherheit in Kürze auch dahin wo sie wirklich hingehört:

    In die offenen OpenSimulator-Viewer, die mit dem ebenfalls offenen OpenSimulator (der übrigens entgegen einem falschen Artikel in Zeit-Online NICHT von Linden Lab entwickelt wurde) in Zukunft wohl als Paketlösung aus 3D-Internetbrowser und universellem modularem 3D-Anwendungsserver das Rückgrat des 3D-Internet bilden werden.

    Grüße,
    Kai Ludwg.

  2. @Kai: Welche Engine wurde denn eingebunden? Ist das schon bekannt? Ist es die Mozilla Gecko-Engine, die auch im FireFox steckt? Ist das schon bekannt?

    Ansonsten muss ich Dir durchaus recht geben. Wir haben lange gewartet und der geschätzte IT-Aufwand, ist, denke ich, überschaubar. Obwohl ich Andererseits denke, dass die Sache nicht ganz so trivial ist. In unseren ersten Experimenten stellt sich nämlich u.a. auch die Security-Frage. Was passiert, wenn ich mich in Second Life durch den avatargeteilten Browser auf einer Social Media-Plattform wie XING oder Facebook eingeloggt bleibe, aber just in diesem Moment mein SL-Client abraucht. Prinzipiell kann dann jeder vorbeilaufende Avatar meine Session übernehmen.

    Ich denke, dass hier entsprechende Entscheidungsprozesse bei Linden Lab notwendig waren, um zu entscheiden, ob man diesen Schritt gehen will oder nicht. Das hat dann nix mit Manntagen für die Implementierung zu tun.

    Zudem wurden für diesen Zweck auf diverse Berechtigungsfunktionen eingebaut.

    Du siehst also, dass ich Linden Lab ein wenig Rückendeckung gebe :-)

    Und dazu eine Frage an Dich. Warum, wenn es nur ein Mannmonat ist, wurde dieses Feature nicht schon längst in die OpenSimulator bzw. den OpenSimulator eingebaut?

    Aber ich erahne bereits Deine Antwort: Prioritäten und Ressourcen, oder?

    LG,

    Andreas

  3. Kai Ludwig says:

    “Welche Engine wurde denn eingebunden? Ist das schon bekannt?”
    Nach kurzem Blick in die Installationsordner nehme ich an, das es sich um den Qt Port von WebKit handelt. About im Viewer sagt dann auch „Qt Webkit Version: 4.6“. Möglicherweise ist dabei auch die Viewer-Gui insgesamt auf Qt4 umgestellt worden. Zumindest legt das Erscheinen der entsprechenden Bibliotheken in der Installation dies nahe. Dies erklärt auch die auf einen Schlag auftauchende darstellbare Medienflut, da diese dann komplett über die Qt4-Bibliotheken läuft.

    “Was passiert, wenn ich mich in Second Life durch den avatargeteilten Browser auf einer Social Media-Plattform wie XING oder Facebook eingeloggt bleibe, aber just in diesem Moment mein SL-Client abraucht. Prinzipiell kann dann jeder vorbeilaufende Avatar meine Session übernehmen.”
    Nein, kann er nicht und es passiert gar nichts. Tests ergaben: Da die Implementierung lediglich die URL über den Server synchronisiert und wohl keinerlei weitere Daten zwischen den Clients direkt oder über den Server austauscht (das war auch der simpelste Ansatz, ohne den Server unnötig anfassen zu müssen; ein zusätzliches synchronisiertes URL-Textfeld pro Texturfläche und ein paar Berechtigungsflags gehen wohl so gerade noch; den Begriff für den bei den Tests neu festgestellten Effekt des „Collaborative Surfing Lag“ patentiert ihr mir bitte) gibt es auch keine gemeinsame Sitzungen und somit auch keine Sicherheitsprobleme. Während User A bei einer Webseite eingeloggt ist, ist User B dies eben nicht. Durch die reine Synchonisierung der URLs sieht User B dann in geschützten Bereichen andere Inhalte auf den selben Webseiten, da Webserver bei vernünftiger Sicherheitsimplementierung dies eben so tun. Kollaboratives surfen wird bei diesem Ansatz ausschließlich durch die aufgerufene Webanwendung ermöglicht, in die sich alle Benutzer dann einzeln einloggen müssen. Hier wurde also überhaupt nichts Neues erfunden, sondern nur eine vorhandene Open Source Browserengine in den Client mit Gui-on-a-Prim eingebaut und eine URL-basierte Seitensynchronisation umgesetzt. Dieser Ansatz bietet sicher eine Menge netter Möglichkeiten, sollte aber eben aus Sicht des Entwicklungsaufwandes eher als Quantensprung bezeichnet werden.
    Diese Art von Entwicklung passt aber eben auch genau in das Bild, welches Linden Lab uns seit einigen Jahren zeigt. Es wird, so weit es geht, funktionserweiternd rumgebastelt. Dabei kommen nach langer Entwicklung selten mal ein paar nette Erweiterungen raus. In der Zwischenzeit entwickeln andere die gleiche Technologie gleich von Grund auf neu. Es wäre also an der Zeit, dass Linden Lab seinen ganzen Krempel wegschmeißt und sein Second Life auf der Basis von OpenSimulator als echte Version 2.0 solide in die Zukunft führt. Nach meiner Ansicht übrigens die einzige wirklich langfristige Chance für Second Life, inkl. der Notwendigkeit sich mittelfristig der Herausforderung der Teilnahme am in der nächsten Version dann auch sicheren Hypergrid zu stellen. Wenn Linden Lab aber so weiter macht, werden sie das CompuServe des 3D-Internet.

    “Warum, wenn es nur ein Mannmonat ist, wurde dieses Feature nicht schon längst in die OpenSimulator bzw. den OpenSimulator eingebaut?”
    Weil hinter Linden Lab Geld aus der Kuh steckt, die zu Tode gemolken wird. Das wird zwar leider nur vermurkst verwendet, aber immerhin sitzen dort bezahlte Programmierer.
    Hinter allen anderen Entwicklungen im offenen OpenSimulator-Bereich, egal ob Server oder Client steckt kein Geld, bzw. nur gezielte Interessen einzelner Personen und Unternehmen, die nur genau die für ihre Projekte nötigen Dinge entwickeln und zurück in den offenen Quellcode einfließen lassen. Die privat entwickelte Fahrzeugimplementierung, die Intel-Performance-Fixes oder die IBM-Vivox-VoiceChat-Integration sind gute Beispiele. Wenn also noch niemand eine genügend große Motivation zum Thema „Shared Media“ verspürt hat, dann konnte es bisher nicht passieren. Adam Frisbys Artikel zum Thema „Finite Manpower Problem“ ist dazu die beste Antwort: http://www.adamfrisby.com/blog/2008/09/the-finite-manpower-problem-or-why-we-suprisingly-cannot-do-everything-at-once/
    Meine klare Ansage: Gib mir 0,5-1.0 MEUR, dann stell ich Dir mit einem Team in 6 Personenmonaten das 3D-Internet auf die Beine. Bei den aktuellen Strukturen werden wir allerdings waren müssen, bis dies aus den zur Verfügung stehenden Garagenressourcen sich innerhalb der nächsten zwei Jahre von selbst erledigt.
    Technisch gesehen ist OpenSimulator der Server, da muss man das auch nicht einbauen. Und mit dem Viewer haben die Kernentwickler aus lizenztechnischen Gründen keinen Sourcecodekontakt. Die vielen Entwickler offener Viewer werkeln nur an irgendwelchem Feinschliff rum oder entwickeln gleich ganz neue Viewer, die noch überhaupt nicht so weit sind. Insofern ganz klar, da hatte bisher keiner Lust zu. Ich gehe aber davon aus, das sämtliche offenen und auf dem SL-Viewer-Sourcecode basierenden Viewer nun ziemlich schnell ins gemachte Nest hüpfen das Shared-Media Feature nachziehen werden.
    Die OpenSimulator-Entwickler sind übrigens schon dabei die vom neuen Client benötigten Datenstrukturen ins Protokoll zu integrieren. Hier werden wir also bestimmt nicht lange warten müssen.

    Grüße,
    Kai.

  4. Nicht zu vergessen – Webkit QT 4.6 gibt es gerade mal seit Dezember 2009. Bis dahin hat LL keinen Finger krumm gemacht ;)

  5. folgendes Szenario: Drei Avatare loggen sich mit einem eigenen Account bei Wikipedia ein und bearbeiten gleichzeitig die gleiche Seite, Sie stehen vor dem gleichen “Bildschirm” in SL, jeder sieht aber was anderes, nämlich seine eigenen Edits. Stimmt das so?

  6. @moskaliuk

    Hallo Johannes,

    nein, eigentlich nicht. Aber wir sind auch noch am testen. Nur mit Google geht es. Also auf einer Anwendung ohne “echte Session”, wie bei einem Login (OpenBC usw.) geht es wunderbar. Die zuschauenden Avatare sehen die Einträge des Avatar, der gerade die Einträge vornimmt.

    LG,

    Andreas

  7. twuertz says:

    Hallo :-)
    Ich hab mal ein Bisschen mit dem Browser in Sachen Media on a Prim rumexperimentiert und folgendes Beobachtet:

    Sobald man sich auf einer Webseite einloggen muss, ist die Kollaboration Geschichte!
    Das Bearbeiten von WIKI-Seiten ist also eine ganz private Sache, genauso wie das eigene Profil bei Facebook, und Onlinebanking geht auch nicht zu zweit.

    Bei offenen Anwendungen wie Etherpad klappt es aber wunderbar. Hier kann man sogar synchron tippen!
    Wobei bei Google z.B. der Suchtext auf den anderen Clients nicht angezeigt wird, bis die Trefferseite erscheint.

    Als nicht EDVler habe ich natürlich keine Erklärung für dieses Phänomen, aber ich denke, dass es genug kluge Köpfe hier gibt, die da ne Lösung für haben *schiel zu Kai Ludwig rüber*

    Liebe Grüße,
    Tob

  8. Kai Ludwig says:

    Klar doch, ich geb gerne wieder Senf dazu. Jetzt, wo sich ein paar Kommentare angesammelt haben, lohnt es sich auch wieder richtig.

    Bei dem im SL 2.0 Viewer verwendeten Ansatz werden nur die durch den jeweiligen Klick als nächstes ausgelösten URLs vom Server auf alle beteiligten Clients synchronisiert. Genau wie die Media-URL bei allen Teilnehmern gleichzetig ein Video antriggert.

    Dies führt zu folgendem Verhalten:
    a) Webseiten, den die Sitzung egal ist (Das ist meistens alles, wo man sich nicht einloggen muss) laufen wunderbar synchron. Jeder Benutzer sieht ja unter der selben URL auch immer den selben Inhalt. Dynamisch generierte Inhalte innerhalb der Seiten (z. B. Ads) werden sich natürlich unterscheiden.
    b) Webseiten, die eine Sitzung brauchen (Das ist meistens dort, wo man sich einloggen muss und dann auch ab dem Zeitpunkt und in den Bereichen ab dem / für die man sich einloggen muss) laufen im “internen” Bereich nicht mehr synchron. Jeder Benutzer sieht unter der selben URL genau den für seine sich aus Login/Rechte/Sitzungszustand ergebende Situation bedingten Inhalt.
    c) Die coole Ausnahme stellen Webseiten dar, die explizit für Onlinezusammenarbeit ausgelegt sind (Collaborative Whiteboard, EtherPad, usw.). Hier werden die Aktionen der Benutzer explizit über die Webapplikation und die auf den Clients im Hintergrund aktive Browserengine synchronisiert, daher klappt das, ohne das der SL Viewer oder der SL Server hier etwas von mitbekommt.

    Die Beobachtung, dass man nicht sieht, was die anderen Benutzer in irgendwelche Eingabefelder eintippen, stimmt damit überein. Es werden ja keinerlei Daten zwischen zwischen den SL Clients synchronisiert, der SL-Server wechselt nur die URLs und die Webapplikation macht da auch nichts. Deshalb passiert da auch nichts.

    Abschliessendes Beispiel: Keiner sähe, was ich in das hier liegende Kommentarfeld eintippe (tuts im Flachweb ja auch nicht), bis ich auf Submit drücke. Dann wird aber die URL neu angefordert (alle Viewer bekommen das vom SL Server gesagt) und alle diese Seite auch sehenden SL Clients bekommen nach dem Reload dann den fertigen Kommentar zu sehen, da die SLTalk-Webseite diesen ja dann für alle darstellt.

    Das von LL gewählte Konzept besticht durch seine Einfachheit. Es ist ungefähr so simpel implementiert, wie damals die Idee mit den Sculpties (einfach eine neue synchronisierte Texture und den Rest erledigt der Viewer) und bringt trotzdem eine erhebliche zusätzliche Funktionalität.

  9. Kai Ludwig says:

    Noch hintendrauf:

    Probiert mal http://dabbleboard.com gemeinsam aus und macht ein schickes Video davon. Das müsste eigentlich klappen, da es wie EtherPad arbeitet.

  10. @Kai: Denkst Du man könnte einen modifizierten Proxy schrauben zwischen dem Media on a Prim und der eigentlichen Anwendungen. Idee ist folgende: Der Proxy loggt sich zu beispielsweise OpenBC, Moodle oder Facebook ein. Media on a Prim stellt jetzt nur ne “gekapselte” Session zum Prox her, während der Proxy die “eingeloggte” Sitzung zur Endanwendung herstellt. Ziel sollte echte Kollaboration sein in SL – auch mit Webanwendungen, die eine Sitzung benötigen?

  11. Kai Ludwig says:

    Das macht vom Aufwand her keinen Sinn und ist mit dem Ansatz als universeller Proxy eher nur von theoretischem Interesse. Echte Onlinekollaborationsfähigheit lässt sich nicht einfach generell von aussen über bestehende Webanwendungen ziehen, sondern muss von innen her individuell in der Systemarchitektur verankert werden.

    Da ist es besser, in die jeweiligen Zielanwendungen an den nötigen Stellen echte Kollaborationsfähigkeit einzubauen bzw. auf bereits vorhandene echte Kollaborationsanwendungen auszuweichen.

    OpenBC, Moodle und Facebook sind vom Anwendungsbereich und vom Konzept her auch gar nicht für direkte Onlinekollaboration ausgelegt. Und für bei Arbeitsprozessen einsetzbare Tools wie Whiteboard, Editor usw. gibt es bereits fertige Webanwendungen.

    Ein Proxy mit der von Dir genannten Funktionalität ist vom Konzept her eine komplizierte Sache und bzgl. der Koordination der Zugriffsberechtigungen kommt man schnell in Teufels Küche.

    Also eher die Empfehlung: “Nicht machen!”

  12. @Kai: Ich sehe schon, ich muss die Intension dahinter ausführen :-) In Second Life sind bereits viele Universitäten und Bildungsträger vertreten, die – das 3D-Internet in aller Ehre – operativ gerade mal dabei sind, Moodle einzuführen. Jetzt wäre es doch kool, diese im Medium bereits bestehende Zielgruppe mit einem “Case” zu beliefern, der Sinn macht: nämlich Moodleschulungen anzubieten. Der Bedarf bzw. meine Anforderung hat also nix damit zu tun, dass ich Moodle “echt” kollaborativ nutzen will. Ich will vielmehr eine Session in 3D machen, mit sagen wir 20 Lehrern, die wie folgt aussieht:

    (1) 20 Lehrer treffen sich mit mir InWorld.

    (2) Mertens präsentiert Moodle oder WebAnwendung X InWorld und erklärt die Funktionen bzw. “turnt” vor.

    (3) Anschließend teile ich die 20 Lehrer in 5 Gruppen a vier Personen. Jede Gruppe bekommt ein “Moodle on a Prim” und soll gemeinsam etwas erarbeiten

    Das wäre also so in etwa der Case. Natürlich könnte ich das vorturnen von “hinten durch die Brust” abstreamen und wieder auf eine Media-on-a-Prim-Wand darstellen. Spätestens aber, wenn ein Lehrer die “Maus” innerhalb einer Moodle-Session an einen anderen Lehrer “abgeben” möchte, geht dass nicht mehr, abgesehen von dem Delay beim streamen.

    How ever, vielleicht ist das ja die Chance, OpenSimulator noch mehr nach vorne zu bringen, dieses Feature nämlich würde mich adhoc befähigen OpenSimulator als Konferenzing und Learningumgebung anzusehen, in der ich JEDE Webanwendung schulen kann – und zwar unter sozialen Gesichtpunkten einer Gruppe, die GEMEINSAM in einem Raum lernt!

  13. >> bereits bestehende Zielgruppe mit einem “Case” zu beliefern

    ich glaubs wohl!

  14. Kai Ludwig says:

    Hab ich verstanden.

    Was Du brauchst ist online webbased Desktopsharing mit einfacher Präsentatorwechseloption oder von vorneherein gemeinsamer Bedienung.

    Lass mal bitte Tobias http://www.webex.de daraufhin überprüfen. Es könnte durchaus sein, das man mit WebEx-On-A-Prim genau die Art von Kollaboration hinbekommt, die Du brauchst. Und vielleicht gibt es auch irgendwo im Internet eine andere Variante von online webbased Desktopsharing, die die gewünschte Funktonalität bietet.

    Ich hab da leider keine Zeit zum austesten. Die Entwicklung einer proxybasierten Lösung halte ich aber für viel zu aufwänding, besonders vor dem Hintergund evtl. bereits existierender Webdienste, die das Thema bereits in Deinem Sinne bieten.

    Da es sich bei der LL Krückenlösung (ehrlich geasgt, mehr bekommen die auch in ihrem monolithischen SL nicht mehr hin, sorry) nur um einfaches Flachwebbrowser-On-A-Prim handelt, muss man versuchen bereits kollaborationserweiterte Flachwebanwendungen zu nutzen und so den LL Flaschenhals zu umgehen.

    Auf das bereits in der Systemarchitektur für die Zielfunktionalität ungeeignete Verfahren per aufgesetzten Workarounds die angesprochene Funktionalität aufzupropfen ist nach meiner IT-Erfahrung eine technologische und aufwändsmäßige Katastrophe.

    Ich mach so was auf keinen Fall und kann auch nur jedem davon abraten. Und wer es trotzdem versucht, soll sich hinterher nicht beklagen, wenn es mit Ansage nicht klappt.

    Grüße,
    Kai.

  15. Stefan says:

    Das 3D-Video erinnert mich sehr an das Buch “Sylvestergespräche eines Sechsecks”.
    Wobei auch in dem Video der 3D-Blick auf 2D nur als Grundlage für die Vorstellung für einen 4D-Blick auf 3D dienen soll.
    Huh, guckt da etwa gerade jemand in mein Zimmer? :-)

Trackbacks

  1. [...] Voraussetzungen?Die technologischen Voraussetzungen sind DA: Nicht zuletzt mit dem Viewer 2.0 sind Dimensionen der virtuellen Zusammenarbeit geschaffen worden (Stichwort: Shared Media), allein [...]

Ihre Meinung ist uns wichtig

*