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