Schön daran ist, dass die Entwicklungen (wenn es auch leider nur wenige sind) wenigstens auch sofort in die anderen offenen OpenSimulator-Viewer einfliessen werden.

Zumindest, wenn der SL-Viewer 2.0 immer noch Open Source ist, was er aufgrund der GPL-Lizenz des zugrundeliegenden SL 1.xx Viewers aber definitiv sein muss.

Wenn man die Zeit in Betracht zieht, die LL für die Entwicklung der 2.0 Version (die auf der Basis der Featureliste aber eigentlich keine Erhöhung der Hauptreleasenummer erlaubt) benötigt hat, ist die Ausbeute eher dünn:
- UI umsortiert und eingehübscht.
- Endlich mal clientseitig eine ordentlich HTML-rendering-Engine eingebunden.
- Zwei neue Funktionstexturen für den Avatar ins Protokoll aufgenommen.

Eine nette Zuarbeit für den offenen Viewer Entwicklungsprozess, die auch den OpenSimulator-Viewern zu Gute kommt, aber keine Revolution. Und keine wesentlichen Funktionserweiterungen am monolitischen Servercode, da ist auch nichts mehr zu erwarten.

@LL: Trotzdem ein Dankeschön! Aber macht bitte nicht so einen extremen Wind darum, hier wurde keinesfalls die Kernfusion endeckt. Wenn ihr wirlich einen Knaller braucht, fragt mal unsere Experten. Wir können euch da defintiv in die Zukunft helfen.

---

Ich finde, die auf SLTalk / Avameo http://www.avameo.de/index.php/2010/02/24/das-3d-internet-saugt-das-2d-internet-in-sich-auf/#comment-56540 sich anbahnende Technologiediskussion ist wichtig, daher spiegele ich sie nach hier (zwei Teile wegen der technischen Kommentarlängenbegrenzung):

—————————————————————————————————————————-
“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 Ludwig.
—————————————————————————————————————————-
@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
—————————————————————————————————————————-

---

Und hier der zweite Teil:
—————————————————————————————————————————-
“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.

---

Und der der Dritte:

...
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.
—————————————————————————————————————————-

---

Aus der Diskussion auf SLTalk ergab sich noch eine interessante Zusammenfassung:

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 gleichzeitig 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.

---