On 20/08/10 23:01, Toni Alatalo wrote:
Justin Clark-Casey kirjoitti:
Do you guys see any problems with storing and manipulating dynamic
data via the OSD classes in libopenmetaverse?
Seems fine so far, but we haven't done anything with it yet. May start
with it soon as are starting to use custom scene entity data on the
viewer side more, and have now the APIs in place there for addons /
scripts to add and use custom data which needs to be synched via and
stored on the server.
Cool.
Would Adam's SOG/SOP refactor plan be essientally what you're thinking
here, or do you see this somehow differently? I don't recall him needing
I'm not sure. If you could provide a reference I'd be obliged.
http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html
.. has a link to the pdf with diagrams etc. about the plan.
The first part is now in opensim git in the soprefactor branch,
http://opensimulator.org/viewgit/?a=shortlog&p=opensim&h=refs/heads/soprefactor
I noticed Adam had also used a OSDMap to store the component info -
perhaps this is very similar to your dynamicattributes branch?
I skimmed the code changes so far and things look similar on the surface. I'll take a look in more depth as Adam starts
to fill the branch out. If they are achieving the same thing then there's no point duplicating functionality - but if
both are using OSDMap then I imagine that any work done with one should be not so hard to transfer to the other.
Regards,
Justin.
~Toni
We need this quite critically for RealXtend, not only because extend the
scene for core functionality, but have worked for long now to allow
arbitrary data in custom apps that anyone can write for the platform.
I'm sure there are good ways to collaborate to get this done somehow --
Adam has told that his work is taking a long time still, so perhaps
others like our team& you and other devs can speed things up.
I still want to implement this, though it's prone now to slipping down
my priority list as other things bubble up. My original code also only
concerned in memory storage. Persistent storage could be implemented
simply by [de]serializing the OSDMap.
What I will probably do is chuck the code up on a branch, implement
storage and see what you guys think. I'd very much like input from
people who would make use of it, since my driving use case (moap) has
disappeared.
Justin
~Toni
John
-----Original Message-----
From: [email protected] [mailto:opensim-dev-
[email protected]] On Behalf Of Justin Clark-Casey
Sent: Thursday, July 29, 2010 8:55 AM
To: [email protected]
Subject: Re: [Opensim-dev] Proposal: Introduce key:value pair
dictionaries
into SOP and PrimitiveBaseShape
On 29/07/10 01:40, Dahlia Trimble wrote:
Similar to the OSDMap in libomv?
Not dissimilar, though the in-memory maps in OpenSim would need to
hold
arbitrary data types. We couldn't use OSDMap directly unless we were
happy to serialize objects to and from OSD for every get and set
(or change
the values directly in the OSD representation, which might be an
idea).
On Wed, Jul 28, 2010 at 2:39 PM, Justin Clark-Casey
<[email protected]<mailto:[email protected]>> wrote:
Hi there. Whilst implementing media-on-a-prim, I've been keeping as
much code in the MOAP region module as possible.
I'm quite impressed with how feasible this is. However, there
remain three major structures where the core of OpenSim has to
understand something about media on a prim.
1) Database plugins - to get/put values to named database columns
(e.g. prims.MediaURL).
2) Script functions (e.g. llGetPrimMediaParams()).
3) Scene objects (PrimitiveBaseShape.Media and
SceneObjectPart.MediaURL).
It's difficult to do anything right now about (1) and (2), but I
believe there is an opportunity to address (3).
What I would like to do is introduce dictionaries into
PrimitiveBaseShape and SceneObjectPart that would supplement
existing fields by storing arbitrary key/value pairs. So instead of
having to hardcode a new MediaURL property on SceneObjectPart I
could instead get/put the data as something like
SceneObjectPart.Values["MediaURL"].
Thus, the dictionaries can act as blackboards for communication
between plugins and modules without the core of OpenSim having to
get involved. I think that this would move us a tiny way towards
our vision of being a generic virtual environment platform and away
from hardcoded Second Life specifics, and make it easier to write
more ambitious region modules without additions to core.
Thoughts?
--
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]<mailto:[email protected]>
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)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
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)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
