<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think the idea is that if module X wants to add some attributes onto an SOP, it does it by adding an OSDMap named “X” and puts its individual attributes therein.
That organizes the values, prevents name space collisions and gives a trace to the module the attribute came from if there are any problems.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The “no less than 4 characters” is to keep people playing nice. I don’t think it is necessary to enforce any rule like that in code. I would think that, with
this feature, we are not trying to prevent griefing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-- ra<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev-bounces@lists.berlios.de]
<b>On Behalf Of </b>Dahlia Trimble<br>
<b>Sent:</b> Friday, January 18, 2013 4:11 PM<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] IRegisterInterface for extending scene entities<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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?<o:p></o:p></p>
<div>
<p class="MsoNormal">On Fri, Jan 18, 2013 at 3:46 PM, Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Alright, I'm going to suggest<br>
<br>
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).<br>
<br>
2. Within this map, attribute names and further OSDMap or other structures are entirely up to the caller.<br>
<br>
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.<br>
<br>
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.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
On 18/01/13 22:09, Adams, Robert wrote:<o:p></o:p></p>
<p class="MsoNormal">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.<br>
<br>
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.<br>
<br>
What do you say? I am +1. How about everyone else? It is a start.<br>
<br>
-- ra<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Justin
Clark-Casey<br>
Sent: Friday, January 04, 2013 5:18 PM<br>
To: <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities<br>
<br>
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.<br>
<br>
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.<br>
<br>
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<br>
<br>
On 04/01/13 21:22, Adams, Robert wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.<br>
<br>
For instance, the JSONStore module (<a href="http://opensimulator.org/wiki/JsonStore_Module" target="_blank">http://opensimulator.org/wiki/JsonStore_Module</a>) 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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
-- ra<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a><br>
[mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Oren<br>
Hurvitz<br>
Sent: Friday, January 04, 2013 11:22 AM<br>
To: <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene<br>
entities<br>
<br>
The typing problem is already solved since the dynamic attributes are implemented using OSD.<br>
<br>
Your proposal is much more complicated than the currently proposed<br>
attributes, and I don't want to suppress a good solution in favor of a<br>
perfect solution that might never be implemented (I assume you're too<br>
busy with BulletSim to do this...) Furthermore, it would prevent a<br>
very exciting<br>
use-case: the ability to use dynamic attributes from a script, using OSSL.<br>
(Well, unless you add a module for that specific purpose, but in that<br>
case you just added a layer of indirection around the key-value<br>
store.)<br>
<br>
Oren<br>
<br>
<br>
<br>
--<br>
View this message in context:<br>
<a href="http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extend" target="_blank">http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extend</a><br>
ing-scene-entities-tp7578406p7578425.html<br>
Sent from the opensim-dev mailing list archive at Nabble.com.<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
--<br>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
-- <br>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>