On 12/08/10 11:39, Toni Alatalo wrote:
On ke, 2010-08-04 at 21:38 +0100, Justin Clark-Casey wrote:
Thanks a lot for reporting this adventure!
to be working fine. However, using the OSD representation of MediaEntry got
complicated and so I would rather implement
dynamic attributes separately to reduce complexity.
So how would you go about it?
Actually, my initial thought would still be to implement them as an OSDMap - all I meant by the above was that I didn't
want to do this at the same time as implementing moap (particularly as I hadn't started out this way).
However, there are various problems with using the OSD classes and serialization (as outlined earlier on in that post).
I'm not sure if these are major enough to cause a rethink.
Do you guys see any problems with storing and manipulating dynamic data via the
OSD classes in libopenmetaverse?
Sorry for the tl;dr but I think that this is a very interesting area. If we
could also save the dynamic attributes to
persistent storage (rather than breaking them up into separate columns) and
have a script infrastructure where functions
can be dynamically defined then we could be some of the way to properly
separating SL modules and core. Core could be
separated out as a content neutral component rather than as part of an
ever-expanding monolith.
Do you mean this is essentially the only sane way? I don't quite see why
the script infrastructure would need to change to allow storage for
other uses, but this is probably due to not reading all of the post
properly yet (sorry) :p
I was really only referring to script functions because MOAP needed to implement some. This was just enough facet of
being able to implement functionality without core having to 'understand' it - it's orthogonal to the issue of storing
dynamic attributes.
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
to touch script infra etc. to begin with.
I'm not sure. If you could provide a reference I'd be obliged.
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
--
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
