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? > 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 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. 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. > Justin ~Toni > > John > > > >> -----Original Message----- > >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > >> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey > >> Sent: Thursday, July 29, 2010 8:55 AM > >> To: opensim-dev@lists.berlios.de > >> 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 > >>> <jjusti...@googlemail.com<mailto:jjusti...@googlemail.com>> 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 > >>> Opensim-dev@lists.berlios.de<mailto: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) > >> http://justincc.org > >> http://twitter.com/justincc > >> _______________________________________________ > >> 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 > > > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
