> Hi Kelly, > > Thanks for such a prompt and detailed response! > > I suspected as much after reviewing the available messages. I had been > holding out hope that one could retrieve/de-serialize the asset on the > client, make the requisite changes to the object's contents, and then > serialize/store the updated asset file. However, am I correct that the > asset server is in fact not accessible by clients directly? It seems > that this must be the case, but strangely I've had a hard time confirming > it via google. >
That is correct. The viewer does not have any direct access to the asset server, or the database. All such access goes through the simulator. > So the real problem is that the simulator must act as the go-between > for the viewer and the asset server, and the simulator code currently > only supports manipulating live object inventories. Thus, any > viewer-only attempt at supporting a feature like the one described in > VWR-2427 would inevitably be an ugly (and most likely unreliable) > hack. > > Well, I shall have to find something else to serve as my hobby project. > Thanks again! > > P. Spoonhammer > > On Jan 18, 2009, at 7:19 PM, [email protected] wrote: > >> Unfortunately the design of SL makes this kind of feature rather >> difficult, and especially more difficult as a viewer-only project. >> >> Agent inventory is conceptually a set of links or shortcuts to assets >> (objects, sounds, textures etc). When you manipulate agent >> inventory data >> is updated in a database, but the actual assets don't change. >> >> Assets on the other hand are *static files* that live on a (fancy, >> high >> performance) http server. This includes 'objects' which live in >> LLSD xml >> format, including references to any inventory contents on them (and >> script >> state and lots more). >> >> When you rez an item the asset is fetched from the asset servers, >> deserialized and instantiated in world. Objects in world are *not* >> assets, they are objects. When you manipulate an object (or its >> inventory) in world, it is the in memory version of that object >> that is >> changing on the simulator. When you take the object (or when it gets >> de-rezed back to inventory for any reason) then the object is >> serialized >> and saved as a new asset. >> >> With the way the system currently is, modifying an object (whether in >> inventory or not) requires: >> * An http fetch of the asset linked to by the inventory item >> * Deserialization of that asset into memory >> * Viewing and/or modification of the object >> * Serialization of the newly modified object >> * An http PUT to write a new asset >> * Updating the inventory item references. >> >> That is, I think, a lot of work. And a whole lot more, if it is >> possible >> at all, to get similar behavior with a viewer only project. >> >> - Kelly >> >> >> >>> Hello all, >>> >>> I'm looking for a fun hobby project, and improving the SL client >>> would help this humble Java programer stay current on his C++ skills. >>> >>> I've been wishing for something along the lines of the feature >>> requested in VWR-2427 (https://jira.secondlife.com/browse/VWR-2427) >>> for quite some time. Specifically, I was hoping to enable the editing >>> of an object's inventory without rezzing that object. >>> >>> Unfortunately, a cursory perusal of message_template.msg seems to >>> indicate that the only messages that allow manipulation of an >>> object's inventory are viewer->sim messages that require a rezzed >>> object. Is my little project dead on arrival? Are there no messages >>> that can be used to manipulate inventory based on an agent and >>> item Id? >>> >>> Thanks, >>> -P. Spoonhammer >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
