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 <[email protected]> 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: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Hurliman, John >> Sent: den 21 september 2009 22:05 >> To: [email protected] >> 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: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Hurliman, John >> Sent: Monday, September 21, 2009 12:54 PM >> To: [email protected] >> 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 >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> 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 > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
