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
