[Opensim-dev] IRegisterInterface for extending scene entities

Sat Jan 19 00:10:30 UTC 2013

I'm not seeing the rationale for rule #1. Could you explain it a bit?
Anyway, if there is a good technical reason for it, perhaps OSDMap could be
subclassed and code added to enforce the rule?

On Fri, Jan 18, 2013 at 3:46 PM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> Alright, I'm going to suggest
>
> 1.  That all attributes must be within their own OSDMap, which must be a
> minimum of 4 chars long (maybe this could be relaxed for 'core' stuff).
>
> 2.  Within this map, attribute names and further OSDMap or other
> structures are entirely up to the caller.
>
> 3.  At the initial development stage, everything may change such that
> existing data may no longer be retrieved (e.g. the way this is stored or
> the entire approach may change).  One must not rely on data being present.
>
> 4.  If at all possible, this must be backward and forward compatible with
> other versions of OpenSimulator no matter whether it remains or is altered
> radically.  This should be fine since deserialization will ignore any
> top-level xml nodes that it doesn't recognize.  But we must preserve a
> Postel's law - this was a painful lesson to learn.
>
>
> On 18/01/13 22:09, Adams, Robert wrote:
>
>> I have a need to add more attributes to an SOP (use specified
>> center-of-gravity, user specified mass, rolling friction, ...) and the
>> implementation of Justin's dynamic attributes is just what I need. It does
>> not fulfill my other wishes of adding functionality to SOPs, but it does
>> allow the dynamic addition of new and serialized objects attributes.
>>
>> Can we Just Do It(r)(tm)(sm)? Some comments in the code suggesting a top
>> level naming convention ("prepend attribute names with your module name" or
>> some such) and an admonition to not store large things might be sufficient
>> to control the use of a simple OSDMap.
>>
>> What do you say? I am +1. How about everyone else? It is a start.
>>
>> -- ra
>>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.**berlios.de<opensim-dev-bounces at lists.berlios.de>[mailto:
>> opensim-dev-bounces@**lists.berlios.de<opensim-dev-bounces at lists.berlios.de>]
>> On Behalf Of Justin Clark-Casey
>> Sent: Friday, January 04, 2013 5:18 PM
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities
>>
>> No problem in making this e-mails, Robert - I think this is exactly the
>> kind of discussion that we need.  These are the kind of decisions that
>> we'll be stuck with for a long time so I think we need to think them
>> through, both through discussion and review or proof-of-concept code.
>>
>> I hadn't really properly considered that the JSONStore is close to this.
>>  I suppose one other significant difference is that the current
>> dynamic-attributes effectively stores data per part rather than through a
>> single datastore for the whole region.
>>
>> But even if it does use the blackboard pattern, there still has to be an
>> underlying persistence store, which in this case would be a serialized JSON
>> object that is functionally identical with the OSD Map (I've run out of
>> time today to see if the JSON store enforces type safety in some way).
>>  Really, the code could be very similar, though in terms of formats I would
>> prefer if to avoid further schizophrenia over data storage in
>> OpenSimulator.  If we stored as JSON, for instance, we end up transporting
>> a JSON object in XML... :p
>>
>> On 04/01/13 21:22, Adams, Robert wrote:
>>
>>> I think adding a module allowing scripts to attach dynamic variables to
>>> SOPs is the right level of functionality. Just adding a key/value store is
>>> way too low a level.
>>>
>>> For instance, the JSONStore module (http://opensimulator.org/**
>>> wiki/JsonStore_Module <http://opensimulator.org/wiki/JsonStore_Module>)
>>> creates a dynamic variable storage to share between scripts. Since it's
>>> made for sharing, a script can request events when values are updated. The
>>> module adds, as one piece, functionality for extension and communication
>>> between scripts.
>>>
>>> Does this attribute store enable such? Would a script want to know when
>>> one of the key/value pairs changed? Is polling suitable? Does the usage
>>> case just need static variable addition?
>>>
>>> As to the practical, implementation angle, yes, you are correct that
>>> adding an OSD store on a scene object is simpler. This is an open source
>>> project, after all, so this is just my opinion.
>>>
>>> -- ra
>>>
>>> -----Original Message-----
>>> From: opensim-dev-bounces at lists.**berlios.de<opensim-dev-bounces at lists.berlios.de>
>>> [mailto:opensim-dev-bounces@**lists.berlios.de<opensim-dev-bounces at lists.berlios.de>]
>>> On Behalf Of Oren
>>> Hurvitz
>>> Sent: Friday, January 04, 2013 11:22 AM
>>> To: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] IRegisterInterface for extending scene
>>> entities
>>>
>>> The typing problem is already solved since the dynamic attributes are
>>> implemented using OSD.
>>>
>>> Your proposal is much more complicated than the currently proposed
>>> attributes, and I don't want to suppress a good solution in favor of a
>>> perfect solution that might never be implemented (I assume you're too
>>> busy with BulletSim to do this...) Furthermore, it would prevent a
>>> very exciting
>>> use-case: the ability to use dynamic attributes from a script, using
>>> OSSL.
>>> (Well, unless you add a module for that specific purpose, but in that
>>> case you just added a layer of indirection around the key-value
>>> store.)
>>>
>>> Oren
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://opensim-dev.2196679.n2.**nabble.com/IRegisterInterface-**
>>> for-extend<http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extend>
>>> ing-scene-entities-**tp7578406p7578425.html
>>> Sent from the opensim-dev mailing list archive at Nabble.com.
>>> ______________________________**_________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<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<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>
>>>
>>
>> --
>> Justin Clark-Casey (justincc)
>> OSVW Consulting
>> 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<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<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> 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<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20130118/25b854d3/attachment-0001.html>