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 <[email protected]
<mailto:[email protected]>> 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@lists.__berlios.de
<mailto:[email protected]>
[mailto:opensim-dev-bounces@__lists.berlios.de
<mailto:[email protected]>] On Behalf Of
Justin Clark-Casey
Sent: Friday, January 04, 2013 5:18 PM
To: [email protected] <mailto:[email protected]>
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@lists.__berlios.de
<mailto:[email protected]>
[mailto:opensim-dev-bounces@__lists.berlios.de
<mailto:[email protected]>] On Behalf Of Oren
Hurvitz
Sent: Friday, January 04, 2013 11:22 AM
To: [email protected]
<mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected]
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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
