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: [email protected]
[mailto:[email protected]] On Behalf Of Oren Hurvitz
Sent: Thursday, January 03, 2013 9:48 PM
To: [email protected]
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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
