Hi Blackie,
"ueber das
teleportieren [libary:7ab0c1dd70]Eine Reisemöglichkeit in [SecondLife] um schnell von einem Ort zu einem anderen zu [reisen].[/libary:7ab0c1dd70] von grid zu grid sind wir uns doch sicherlich einige das dies funktionieren wird. "
--> klar, im Juli geschehen -
http://blog.secondlife.com/2008/07/08/ibm-linden-lab-interoperability-announcement/
Ein Grund, weshalb osgrid heute TRUNK fährt, gell. Dort ist OGP eingeflossen.
"wenn ich also teleportiere nehme ich miene sachen nicht mit sindern gridb holt die sachen von grid a. "
--> ein mögliches model, nicht das favorisierte aus den erwähnten Gründen
--> wenn man es im OPG realisieren wollte, müsste man es hier einreichen:
https://jira.secondlife.com/browse/SVC-3156
OPG sieht es nicht vor.
http://wiki.secondlife.com/wiki/Open_Grid_Public_Beta/FAQ "Your inventory will not come with you, and you'll appear as the 'ruthed' or default avatar on external virtual world regions."
--> Das Opensim Inventory-Model REST kennt keine Funktion zum "Abgleich"...
http://opensimulator.org/wiki/REST
--> es gibt drei Ansätze
a) "Proxy by local" - was zu den beschriebenen wirtschaftlichen Themen führen wird - aber schon die
Technik ist die ich auch für nächste Tage favorisiere
http://opensimulator.org/wiki/Hypergrid
Sprich:
Teleport [libary:7ab0c1dd70]Eine Reisemöglichkeit in [SecondLife] um schnell von einem Ort zu einem anderen zu [teleportieren].[/libary:7ab0c1dd70] von A zu B , aus B wird auf den Asset-Server in A zugegriffen - eine lokale Kopie im Cache
erzeugt - und in
Grid [libary:7ab0c1dd70]Begriff für das [SecondLife] Server-Netzwerk[/libary:7ab0c1dd70] B Assetserver hochgeladen.
b) lokale Assets (ggf. auch ergänzend) - selbe Idee wie vorher, nur zeitversetzt und ohne Eingriff in Server zu regeln.
Auf Basis z.B. libsl zieht man während man in
Grid [libary:7ab0c1dd70]Begriff für das [SecondLife] Server-Netzwerk[/libary:7ab0c1dd70] A ist eine Kopie ins lokale Inventory.
In
Grid [libary:7ab0c1dd70]Begriff für das [SecondLife] Server-Netzwerk[/libary:7ab0c1dd70] B schiebt man es wieder hoch.
Entsprechen featurerequest gibts bei allen wichtigen Viewer, bzw. auch immer mal wieder im opensim-dev IRC .
man könnte sagen Second Inventory integriert.
c) zentrale Assetdienste (die genau den von dir beschriebenen Transfer verhindern)
"In the proposed architecture, control of assets is moved from grid owners to content owners"
http://opensimulator.org/wiki/AssetServerProposal
Auch Erweiterungen zum inworld-scripting sind dazu bereits eingereicht, z.B.
osRezFromURL(string url, vector pos, vector vel, rotation rot, integer param) - calls on_rez
was die sicherheit von texturen angeht, die sind natuerlich a nur solange sicher, solange sie nicht einer fremden sim hochgeladen werden, das ist auch jetzt im osgrid oder anderen grids so.
--> die sind nur solange sicher, solange sie nicht benutzt oder angezeigt werden. Dazu brauchts ja keinen Copyboot sondern z.B.
die Debug-Schnittstelle von OpenGL und ein wenig freeware...
Texturen [libary:7ab0c1dd70][Bilddateien] welche über ein [Objekt] gelegt werden kann. Neue [Texturen] müssen vor einer Verwendung auf einem [Objekt] in [SecondLife] für ca. 10 [L$] hochgeladen werden[/libary:7ab0c1dd70] im Überfluß.
aber man kann ja auch UUIDS direct ansprechen, das wird dann sich sicherlich mehr durchsetzen um seine assets eben nicht auf die sim zu laden.
--> Ein Beispiel für die UUID-Thematik die immer aufpopt währe übrigens auch hier:
http://forge.opensimulator.org/gf/p...er/?action=TrackerItemEdit&tracker_item_id=54
--> aber direkt ansprechen ? wenn es GUID´s wären, dann vom Konzept her ja. Aber UUID´s aus meiner Sicht eher nicht.
vieleicht muss man dann auch nach user und asset/inventory groesse variabel bezahlen ...
--> stimme ich vollkommen zu.
das eine hat meiner meinung nach mit dem anderen ncihts zu tun.
bzw
man sollte aber entwicklung und forschung nicht vom geld abhaengig machen ....
--> klingt mir persönlich zu sehr nach perpetuum mobile... irgendwer muss die Party zahlen...
Ich könnte nu noch was C# code aus den angesprochenen Modulen nachwerfen, u.a. viewer-patche für Versuche zu lokalem Inventory. Ich gehe aber davon aus, du hast ne libsl.
Insofern mag ich zu dem Diskussionsthema jetzt schliessen.
cu
Ralf