The whole approach to objects and assets needs to change anyway, because of interop. Interop is a process --- it doesn't appear suddenly out of nowhere, you have to pave the way by evolving your code into a more flexible form.
There is an implicit assumption in the viewer that everything is stored in one world's own repository, and that this world also holds all ownership and permissions data. This is changing as more grids and independent asset services appear, leading to a mashup scenario in which a region will contain elements which are held authoritatively in a variety of places elsewhere. As you are developing your own viewer, I suggest that you revamp your object and asset data and metadata handling to include querying external services, because that is where everyone is heading. VWRAP is moving in that direction by decoupling all services, realXtend's Naali already features external WebDAV-based inventories, Opensim has long had Hypergrid which reflects asset requests back to a traveller's home region, and the new Connector system in Opensim offers huge scope for non-centralized object and asset authority. The days of centralized objects and assets are coming to an end, and new viewer code needs to take that into account. Morgaine. ================================= On Sat, Mar 6, 2010 at 12:52 AM, Rob Nelson <nexisentertainm...@gmail.com>wrote: > While working on my viewer's object handling stuff, I happened across a > rather fundamental flaw in the SL viewer's architecture. > > When one considers filesystem permissions or even database permissions, > you notice that permissions are generally attached to the object that a > user attempts to access, or the permissions are obtainable from a > central source that has a simple way to grab the permissions. > > >From my casual glance at the viewer code, I noticed that the latter is > the case in the LL viewer. However, there's a rather large problem for > those of us who are writing client-side scripting APIs. > > Consider a user in a sandbox who wants to clean up his mess. If he were > using a viewer based on LibOMV, all the viewer would have to do is loop > through the region's object dictionary and return/delete objects that he > owns. In the LL viewer (correct me if I'm wrong), LLSelectMgr actually > returns the permissions (*and owner/creator info*) , so the viewer would > have to select each and every object within the sim to grab its > permissions, which seems rather wasteful of bandwidth, and troublesome > in general. This works fine for situations where the object is selected > anyway (when building or right-clicking), but it's horribly inefficient > for scripting. > > I haven't dug deep enough yet to fully grasp what is going on in > LLSelectMgr, but it seems to me that it would be a lot more efficient to > simply attach the permissions with each object's properties when they > are sent to the client by the server, eliminating the need for scripts > (and bots) to have to spam the server requesting permissions. > > Fred Rookstown > Luna Viewer > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
