I think this is a good point - if script access to dynamic attributes is every considered to be 'secure' (which might be
a debatable point), one can't allow them to store indefinite amounts of data there. Even in an 'insecure' situation, it
might be best to stop scripts being able to casually do this (which perhaps comes down to the debate I think that Mic
and I were having about whether you assume the feature users are completely dumb or completely smart or try not to give
them so much rope that they can easily accidentally hang themselves - I might be paraphrasing).
The same thing is really true of the vanilla JsonStore since this is not limited either right now and could suck up all
the memory even if its not persisted.
On 07/02/13 02:11, Melanie wrote:
A word of caution:
Many people have scripts that would store copious amounts of data.
Some limits need to be placed on the overall storage given to a
script so it becomes unattractive to store lots of data in the
simulator. Scripts needing lots of storage should use a web server,
not sim resources.
Melanie
On 07/02/2013 02:59, Mic Bowman wrote:
for discussion purposes...
added the jsonstore connection to the dynamic attributes. here's an example
of an LSL script that sets the attributes (create a notecard called
JsonData with some json structure inside it)... you can interrogate the
store through channel 30... eg "/30 jstoretest.test1.field"
btw... i really think that hooking up the object store with a variant of
llrezobject() would be very good. it would make passing more complex
initialization parameters a LOT easier (better than the one integer you get
right now). i'm doing this with a modified version that uses a global
jsonstore...
--mic
integer iChannel = 30;
string sInitCard = "JsonData";
key kStoreID;
InitializeObjectStore()
{
llOwnerSay("initializing the object store");
JsonSetValueJson(kStoreID,"jstoretest","{'test1': {'field' : 22}}");
JsonReadNotecard(kStoreID,"jstoretest", sInitCard);
}
default
{
state_entry()
{
kStoreID = JsonAttachObjectStore();
if (JsonTestPathJson(kStoreID,"jstoretest") == 0)
InitializeObjectStore();
llOwnerSay("object store is " + JsonGetValueJson(kStoreID,"."));
llListen(iChannel,"",llGetOwner(),"");
}
listen(integer ch, string name, key id, string msg)
{
if (ch == iChannel)
{
list tokens = llParseString2List(msg,[" "],[]);
string path = JsonList2Path(tokens);
string value = JsonGetValueJson(kStoreID,path);
llOwnerSay(path + " == " + value);
}
}
}
On Wed, Feb 6, 2013 at 3:00 PM, Mic Bowman <cmick...@gmail.com> wrote:
one more thing... is there a strong reason for XML serialization as
opposed to json? (I assume the primary reason is for consistency with other
properties.) the OSDMap data structure corresponds fairly closely to JSON.
serializing works fine for either format though it is easy to provide an
xml document that will not deserialize into an OSDMap.
--mic
On Wed, Feb 6, 2013 at 1:58 PM, Mic Bowman <cmick...@gmail.com> 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.
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. :-)
--mic
On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey <
jjusti...@googlemail.com> 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<opensim-dev-boun...@lists.berlios.de>[mailto:
opensim-dev-bounces@**lists.berlios.de<opensim-dev-boun...@lists.berlios.de>]
On Behalf Of Justin Clark-Casey
Sent: Friday, January 25, 2013 5:14 PM
To: opensim-dev@lists.berlios.de
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
Opensim-dev@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@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@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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
