[Opensim-dev] Proposal: Introduce key:value pair dictionaries into SOP and PrimitiveBaseShape

Justin Clark-Casey jjustincc at googlemail.com
Thu Aug 12 22:14:40 UTC 2010


On 12/08/10 11:39, Toni Alatalo wrote:
> On ke, 2010-08-04 at 21:38 +0100, Justin Clark-Casey wrote:
>
> Thanks a lot for reporting this adventure!
>
>> to be working fine.  However, using the OSD representation of MediaEntry got complicated and so I would rather implement
>> dynamic attributes separately to reduce complexity.
>
> So how would you go about it?

Actually, my initial thought would still be to implement them as an OSDMap - all I meant by the above was that I didn't 
want to do this at the same time as implementing moap (particularly as I hadn't started out this way).

However, there are various problems with using the OSD classes and serialization (as outlined earlier on in that post). 
  I'm not sure if these are major enough to cause a rethink.

Do you guys see any problems with storing and manipulating dynamic data via the OSD classes in libopenmetaverse?

>
>> Sorry for the tl;dr but I think that this is a very interesting area.  If we could also save the dynamic attributes to
>> persistent storage (rather than breaking them up into separate columns) and have a script infrastructure where functions
>> can be dynamically defined then we could be some of the way to properly separating SL modules and core.  Core could be
>> separated out as a content neutral component rather than as part of an ever-expanding monolith.
>
> Do you mean this is essentially the only sane way? I don't quite see why
> the script infrastructure would need to change to allow storage for
> other uses, but this is probably due to not reading all of the post
> properly yet (sorry) :p

I was really only referring to script functions because MOAP needed to implement some.  This was just enough facet of 
being able to implement functionality without core having to 'understand' it - it's orthogonal to the issue of storing 
dynamic attributes.

>
> Would Adam's SOG/SOP refactor plan be essientally what you're thinking
> here, or do you see this somehow differently? I don't recall him needing
> to touch script infra etc. to begin with.

I'm not sure.  If you could provide a reference I'd be obliged.

>
> We need this quite critically for RealXtend, not only because extend the
> scene for core functionality, but have worked for long now to allow
> arbitrary data in custom apps that anyone can write for the platform.
> I'm sure there are good ways to collaborate to get this done somehow --
> Adam has told that his work is taking a long time still, so perhaps
> others like our team&  you and other devs can speed things up.

I still want to implement this, though it's prone now to slipping down my priority list as other things bubble up.  My 
original code also only concerned in memory storage.  Persistent storage could be implemented simply by [de]serializing 
the OSDMap.

What I will probably do is chuck the code up on a branch, implement storage and see what you guys think.  I'd very much 
like input from people who would make use of it, since my driving use case (moap) has disappeared.

>
>> Justin
>
> ~Toni
>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>>> bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
>>>> Sent: Thursday, July 29, 2010 8:55 AM
>>>> To: opensim-dev at lists.berlios.de
>>>> Subject: Re: [Opensim-dev] Proposal: Introduce key:value pair dictionaries
>>>> into SOP and PrimitiveBaseShape
>>>>
>>>> On 29/07/10 01:40, Dahlia Trimble wrote:
>>>>> Similar to the OSDMap in libomv?
>>>>
>>>> Not dissimilar, though the in-memory maps in OpenSim would need to hold
>>>> arbitrary data types.  We couldn't use OSDMap directly unless we were
>>>> happy to serialize objects to and from OSD for every get and set (or change
>>>> the values directly in the OSD representation, which might be an idea).
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 28, 2010 at 2:39 PM, Justin Clark-Casey
>>>>> <jjustincc at googlemail.com<mailto:jjustincc at googlemail.com>>   wrote:
>>>>>
>>>>>       Hi there.  Whilst implementing media-on-a-prim, I've been keeping as
>>>>>       much code in the MOAP region module as possible.
>>>>>
>>>>>       I'm quite impressed with how feasible this is.  However, there
>>>>>       remain three major structures where the core of OpenSim has to
>>>>>       understand something about media on a prim.
>>>>>
>>>>>       1)  Database plugins - to get/put values to named database columns
>>>>>       (e.g. prims.MediaURL).
>>>>>       2)  Script functions (e.g. llGetPrimMediaParams()).
>>>>>       3)  Scene objects (PrimitiveBaseShape.Media and
>>>>>       SceneObjectPart.MediaURL).
>>>>>
>>>>>       It's difficult to do anything right now about (1) and (2), but I
>>>>>       believe there is an opportunity to address (3).
>>>>>
>>>>>       What I would like to do is introduce dictionaries into
>>>>>       PrimitiveBaseShape and SceneObjectPart that would supplement
>>>>>       existing fields by storing arbitrary key/value pairs.  So instead of
>>>>>       having to hardcode a new MediaURL property on SceneObjectPart I
>>>>>       could instead get/put the data as something like
>>>>>       SceneObjectPart.Values["MediaURL"].
>>>>>
>>>>>       Thus, the dictionaries can act as blackboards for communication
>>>>>       between plugins and modules without the core of OpenSim having to
>>>>>       get involved.  I think that this would move us a tiny way towards
>>>>>       our vision of being a generic virtual environment platform and away
>>>>>       from hardcoded Second Life specifics, and make it easier to write
>>>>>       more ambitious region modules without additions to core.
>>>>>
>>>>>       Thoughts?
>>>>>
>>>>>       --
>>>>>       Justin Clark-Casey (justincc)
>>>>>       http://justincc.org
>>>>>       http://twitter.com/justincc
>>>>>       _______________________________________________
>>>>>       Opensim-dev mailing list
>>>>>       Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
>>>>>       https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>> --
>>>> Justin Clark-Casey (justincc)
>>>> http://justincc.org
>>>> http://twitter.com/justincc
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


-- 
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc



More information about the Opensim-dev mailing list