I've used Dictionary<string, System.Object> in other projects, only problem is a cast is needed to use the object on retrieval. That can be inferred from the name or using the "is" keyword in C#.
On Thu, Jul 29, 2010 at 8:54 AM, Justin Clark-Casey < [email protected]> wrote: > 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
