On 06/02/13 21:58, Mic Bowman wrote:
Justin,
I took a look at the DAMap data structure & have some questions. What's the
value of explicit methods for the top level
of the structure? It is still possible to have name space collisions since
there is nothing that prevents one module
from writing into another module's "name space". Also, whats your expectation
for locking? The top level accessor locks
the structure, but modules that share the rest of the structure will have to do
their own locking anyway. I guess one
value of controlling the top level is that *IF* modules are making exclusive
access to the structure, the locking is
minimized. Hard to control that, though.
The idea was to separate out DAMap into 'namespaces' (over-reaching name I know) so that distributed users did not
casually overwite each other's data by writing directly to a root OSDMap. Thus, moduleA would always write to a map
under the name "modA" and moduleB under the name "modB" and never the twain would meet.
This doesn't stop modules from deliberately overwriting or deleting each other's data. But if you really wanted to do
that you could always achieve it by directly fiddling with the XML serialization. At least this way, somebody writing a
module just by experimenting with methods rather than reading doc (which is how most people do it, myself included if
I'm being honest) will not casually overwrite the properties of another storer.
You're right about the deficient locking story. At the moment, any module changing its OSDMap directly needs to lock
DAMap, and even DAExampleModule doesn't do this.
But really, it would be better to lock the individual 'namespace' maps for better granularity. I may make this change
if there is no further discussion on this point.
I also think that we need to know what will happen if a module forgets to lock and serialization occurs concurrently
with a map change. What we cannot do is write corrupt XML to the SOP serialization.
Did you get a chance to look at the JsonStore structure? The path-based
accessors are very different than providing
immediate access to the OSDMap. As we discussed, I made that decision to support
the synchronization operations (take &
read) and it removes the exposed OSDMap so that the data structure can be
replaced. I think the path-based accessor is
probably too heavyweight for DAMap... well... maybe... given that we dont have
any examples yet its hard to tell. :-)
Yeah, I really do need to take a closer look. Will try and do that soon,
hopefully Fri.
--mic
On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey <[email protected]
<mailto:[email protected]>> wrote:
Okay, I have now merged this branch (dynamic-attributes2) to master.
Please report any problems (or fix them :)
As this is experimental functionality, if necessary it can be
changed/bug-fixed without any attempt to preserve
existing data. Any code using it should handle the 'expected data not
found' case anyway.
On 26/01/13 19:52, Adams, Robert wrote:
This implementation will work for physics. The physics engine cannot
reference Scene (circular reference
madness) so, on creation of the scene's physics instance, I will pass
in the instance of DAMap (since it is
defined in OpenSim.Framework) much the same way the asset request
method instance is passed in.
I am +2 on this branch's inclusion into master.
-- 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 25, 2013 5:14 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: [Opensim-dev] Dynamic attributes
On 25/01/13 08:40, Oren Hurvitz wrote:
Ok, great. I hope all goes well and this will be added to master
soon.
What do you mean by "put the code in for MSSQL"? The code already
supports MySQL, MSSQL and SQLite.
Apologies - my brain stored the assumption that only MySQL had been
added since that's the only one I remembered
seeing in the commit summaries but I see that the MSSQL code is there.
--
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
