On Wed, Oct 20, 2010 at 1:32 PM, Melanie <mela...@t-data.com> 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 Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev