[Opensim-dev] Thoughts on adding a generic key-value storage system to OpenSim?

[Kyle Hamilton]

If you don't want untyped string/string storage, you could do what the
fbmuck sourceforge project did: it keeps everything in text format in
the data file, but auto-converts based on type information stored at
the beginning of the string.  Only internal primitives have type
information stored in that way; scripts can access this storage, but
if it wants to store more than one type of data in a single "property"
(key/value pair associated with an object), the scripter has to do his
own serialization and unserialization from that.

They also have a hierarchal storage of
object(#)=/key/path/here/of/arbitrary/depth/to/entire/length/1024:value.
 It is possible for a property path to have an unnamed value, and this
is the value of the property path itself.  I believe that having an
object:key:value store would be a very good thing; the best compromise
in the fbmuck project has been to not allow any scripts to directly
hook any primitives (and thus be inadvertently executed by) other
script processes.  The potential for deadlock in that situation is
enormous.  This means, among other things, that there is no support
for "aspects" in the language.

(Then again, the script language is a variant of Forth, with
structured exception handling, arrays, variables of 3 different
scopes, and it's implemented in C.  I'm almost tempted to see if I can
write something like it for OpenSim... but in order to harness its
true power, the program must needs be able to store persistent data
associated with an object, either on itself or on the object itself.)

-Kyle H

On Mon, Sep 21, 2009 at 10:36 PM, Stefan Andersson <lbsa71 at hotmail.com> wrote:
> John,
>
> I'm not a big fan of tall/skinny untyped string/string storage, as I believe
> that approach always come back to bite you in the ass in the end. Adam F did
> propose the same thing a year ago, and I was against it then as well.
>
> Since then, my stance has softened somewhat, as there hasn't really emerged
> any other option than nhibernate (but still, wouldn't that be an option?)
>
> If you can just turn string GetValue(string context, string key) into
>
> bool TryGetValue(string context, string key, out string value)
>
> embracing the Try pattern, I'm 0 on it.
>
> I'm presuming that you're going to implement a behind-the-scene
> module-unique identifier also, so modules don't clash on context? I would
> suggest having an IGenericDataStore factory that produces handlers that are
> private to the modules.
>
> /Stefan
>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> bounces at lists.berlios.de] On Behalf Of Hurliman, John
>> Sent: den 21 september 2009 22:05
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value
>> storage system to OpenSim?
>>
>> Formatting got messed up, that should have looked like this:
>>
>> // returns true if the key was found and data was updated, otherwise
>> false if a new key row was added
>> bool AddOrUpdateKeyValue(string context, string key, string value);
>>
>> // returns true if the key was found and deleted
>> bool DeleteKeyValue(string context, string key);
>>
>> // returns the string value if the key was found, otherwise null
>> string GetValue(string context, string key);
>>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> bounces at lists.berlios.de] On Behalf Of Hurliman, John
>> Sent: Monday, September 21, 2009 12:54 PM
>> To: opensim-dev at lists.berlios.de
>> Subject: [Opensim-dev] Thoughts on adding a generic key-value storage
>> system to OpenSim?
>>
>> A lot of the work going into OpenSim recently has been modularizing the
>> codebase and making it easy for third party developers to write
>> plugins. One feature that I think would really complete the picture
>> would be a (simple) generic data storage interface that leveraged the
>> existing OpenSim storage framework. Most plugins I've seen (and wrote)
>> currently tack on their own database tables, use a simple text file
>> with a custom format, or use some other means of data storage that does
>> not match up with the rest of OpenSim. Adding a new database table that
>> had three columns: [context, key, value] would allow plugins to store
>> key/value mappings (string to string) without worrying about data
>> collisions between plugins or having to implement a custom data store
>> every time.
>>
>> // returns true if the key was found and data was updated, otherwise
>> false if a new key row was added
>> bool AddOrUpdateKeyValue(string context, string key, string value);
>> // returns true if the key was found and deleted
>> bool DeleteKeyValue(string context, string key);
>> // returns the string value if the key was found, otherwise null
>> string GetValue(string context, string key);
>>
>> Although I've been writing extensions for the OpenSim codebase for
>> quite a while, I'm still fairly new to the guts of the system. Does
>> this seem like the correct solution? If so, where would this interface
>> go? I'm happy to write the code to implement this, I just want feedback
>> from the dev community first to see if I'm on track.
>>
>> John
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>