Hi, I pulled your branch into the core repo, where it is now available as dev-appearance. This is based on current 0.7 in my repo and you may wish to sync up.
Melanie Mic Bowman wrote: > here's the repository git://github.com/cmickeyb/opensim.git > > there is still a lot of debugging to do & i need to re-enable the > compatibility. without changes to the login server (and the robust > appearance save) you won't see much benefit. those changes are available for > simian in a separate patch. > > --mic > > > On Wed, Oct 20, 2010 at 1:52 PM, Mic Bowman <[email protected]> wrote: > >> >> >> On Wed, Oct 20, 2010 at 1:32 PM, Melanie <[email protected]> wrote: >> >>> Hi, >>> >>> >> The avatar appearance (avatar service) is a name-value pair storage >>> >> anyway, so it could easily hold the UUIDs of baked textures along >>> >> with the components of the avatar appearance. It could also hold the >>> >> visual params, the question there is to what degree that is useful. >>> >> >>> >> >>> > the encoding i have right now is one string (OSDMap) for all of the >>> > appearance >>> > assets. when i looked at the userdata code, i think every field/value >>> pair >>> > generates >>> > a separate database update. and given that the appearance gets re-saved >>> for >>> > every attachment right now (that is, on login the attachments module >>> forces >>> > a save of the appearance once for each attachment even for attachments >>> that >>> > are already in the appearance data) that seemed like a lot of db writes. >>> > >>> > could you expand the size of the string value that can be stored to >>> medium >>> > string? >>> > that would be enough size to handle the encoding i'm using. >>> > >>> > >>> >>> Having one row for each item is highly desirable, as it is easy to, >>> for instance, programmatically detach a single attachment, or unwear >>> a single wearable, like through a website. Storing the entire >>> appearance in one OSD is not what we would want. The overhead of >>> rewriting 27 rows is negligible in such a small table. >>> >>> >> The way the code currently works... it uses the single encoding for >> agentcircuitdata, clientagentdataupdate, and it uses that encoding in the >> copyto/copyfrom methods in scene presence. I kept the IAvatarData code and >> the get/setavatar functions so that (in theory) i wouldn't have to change >> any of the behavior in the ROBUST AvatarService (so it can still be >> key/value pairs passed around). I've modified the simian connectors to use >> the full encoding (which greatly simplifies the code there). I have not >> looked at how to provide the correct encoding for login from ROBUST. again, >> it was a pretty simple three line code change for simian to send it because >> thats what is being stored directly in the user data. that is, having one >> encoding that spans the services dramatically simplified the login process >> as well. using a separate format for the avatarservice can work... but >> you'll have to encode it in form the login service needs. >> >> --mic >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
