[Opensim-dev] IRegisterInterface for extending scene entities

Adams, Robert robert.adams at intel.com
Fri Jan 4 18:01:58 UTC 2013


Don't mean to be too much of a contrarian, but this has Bad Idea written all over it. I can see someone a year from now not finding that one wiki page which defines these conventions and just doing their own thing. Chaos ensues.

My proposal attached object instances to the SOPs. This has two advantages over a simple key/value store:
	1) the variables and types are defined -- anyone knows what is there and what type they should be.  A key/value store will get into all the "how do you store a float value" issues (string? Float? Is the requestor wants a float and finds a string, should it be converted? Opps. Module A does the string to float conversion but Module B doesn't! Etc. Etc.)
	2) there can be actions/methods on the attached instance -- functions like "return the mesh representation of this object" could be a call to the meshmerizer or a cache lookup or whatever. A key/value store would require all logic to be outside in another wrapper instance class that was associated with the SOP somehow.

The problem with attaching instances is serialization/deserialization. Serialization could be the job of the instance (must implement ISerializable or maybe even ISerializableSOPParasite). Deserialization would require finding the class definition. All that C# reflection magic allows searching for the DLLs and if the defining DLL is not there, well, the code that would be using that function couldn't work anyway.

Anyway, my vote is -1 for an arbitrary key/value store. Especially one that requires naming conventions and logic for understanding what's in that store scattered everywhere.

-- ra


-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Thursday, January 03, 2013 9:48 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities

For namespacing we can take a pointer from MIME types:
1. Keys used by core OpenSim will have no prefix, e.g. "media" or "prop.attr".
2. Keys created outside core OpenSim will use the "vnd." prefix, followed by the name of the creating entity. For example: "vnd.acme.myprop".

We should stick to storing the data in a single field. Database access is much slower than in-memory string manipulation, so for any reasonable amount of data it would be faster to read and write it as part of the existing "prims" table rather than adding additional SQL operations on another table ("primattr"?). And of course, a separate table would be much more complicated to handle and I do like the simple life :)

I did consider a different change: replacing OSD with JSON, which I like because of its simplicity and ubiquity. But I decided that it wouldn't make much of a difference; certainly not worth rewriting working code.

Oren



--
View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578423.html
Sent from the opensim-dev mailing list archive at Nabble.com.
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



More information about the Opensim-dev mailing list