[Opensim-dev] IRegisterInterface for extending scene entities
Justin Clark-Casey
jjustincc at googlemail.com
Sat Jan 19 01:21:51 UTC 2013
My thinking here is to stop unrelated modules using short identifiers (e.g. "a") and colliding with each other or having
to use 'second choice' names. Perhaps something like a UUID or a fragment of a UUID for reasonable uniqueness would be
even better (if less readable).
Yes, I was thinking of enforcement down the line.
On 19/01/13 00:10, Dahlia Trimble wrote:
> 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 <mailto: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 <mailto:opensim-dev-bounces at lists.berlios.de>
> [mailto:opensim-dev-bounces at __lists.berlios.de <mailto: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 <mailto: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 <mailto:opensim-dev-bounces at lists.berlios.de>
> [mailto:opensim-dev-bounces at __lists.berlios.de <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
More information about the Opensim-dev
mailing list