[Opensim-dev] SceneObject* Metadata

[Justin Clark-Casey]

Frisby, Adam wrote:
> +1.
> 
> I guess the question is then - can we make the columns dynamic to allow third party stuff? Mesh was just one example - there's quite a few rex properties now (mesh, collision mesh, material settings x10, etc) -- perhaps if we can serialise all the object properties into a dictionary? <Property, Value>, which the DB adapters can then adjust their tables for[?]
> 
> At this point one of those pure XML DB's might not be a horrible idea. (At least it handles hierarchical data properly)

Maybe one could give the Dictionary object to the DB and let it decide how it wants to handle it.  Then at that layer it 
could either be serialized or something more fancy done in the case of a pure XML db (or just put the data in columns if 
you want to improve performance.

Giving the database a license to do things how it wants is both an advantage and a disadvantage - we've been trying to 
get away from inconsistency between databases recently though much of that was without good reason.

> 
> Adam
> 
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
>> Sent: Wednesday, 26 November 2008 6:46 AM
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] SceneObject* Metadata
>>
>> Frisby, Adam wrote:
>>> Well,
>>>
>>> If we save it in RexEntity - then every storage provider needs to
>> recognise it. RexEntity does and will exist - however when it comes to
>> packaging the data up and putting it in a storage provider, we then
>> need to make customised versions for each. The metadata field provides
>> a convenient way of storing the extra properties in a backwards
>> compatible way.
>> Is a mesh UUID really metadata?  I agree with Melanie - it would seem
>> to be more a property of the object than metadata
>> about the object.  I also see it being generally useful, so I would
>> argue that it would merit a proper column in a
>> region db table.
>>
>> I imagine the entire Metadata dictionary would need serialization into
>> a single column in the regions table.  There
>> would inevitably be a performance cost associated with packing and
>> unpacking such a structure.  However, I do see that
>> one might be generally useful and even necessary for other types of
>> data.
>>
>> Regarding serialization formats for storing inventory - these will need
>> to evolve.  It's already proving to be
>> problematic in any elimination of SOG or general code refactoring
>> (since there's a <SceneObjectGroup> tag in there and
>> everything).  I'm wondering if it wouldn't be better to have separate
>> code serializing SOP rather than just using .NET's
>> object serialization - I think Stefan may have suggested this a couple
>> of times in the past.  Those damn things also
>> really need to have a version number embedded in them, I think.
>>
>>> Adam
>>>
>>>> -----Original Message-----
>>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>>> bounces at lists.berlios.de] On Behalf Of Melanie
>>>> Sent: Wednesday, 26 November 2008 4:58 AM
>>>> To: opensim-dev at lists.berlios.de
>>>> Subject: Re: [Opensim-dev] SceneObject* Metadata
>>>>
>>>> Hi,
>>>>
>>>> ideally, Rex data should be in a RexEntity, not the LLEntity or
>>>> IEntity.
>>>>
>>>> I'm +1 on the metadata as such, but I think meshes should not be
>>>> metadata. As a stopgap measure maybe, but not as an architectural
>>>> choice.
>>>>
>>>> Personally, I see no call to bend over backwards for Rex, What have
>>>> they done for the project or me lately?
>>>>
>>>> If we do change the serialization stuff, let's please make the
>>>> format accommodate coalesced objects, too?
>>>>
>>>> Melanie
>>>>
>>>>
>>>> Frisby, Adam wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I'd like to add another parameter onto SceneObjectPart and group
>>>> called 'Metadata' - Metadata would be a Dictionary<string,string>
>> which
>>>> is serialised with the object when loaded and saved from inventory,
>>>> archives, etc.
>>>>> This change would require all the storage providers to handle the
>> new
>>>> metadata fields. The purpose of this field is mainly to support
>> things
>>>> that the stock OpenSim parts do not - without breaking
>> compatibility.
>>>>> An example of such usage would be a "MeshUUID" metafield for the
>>>> Modular Rex components we're building inside DeepThink - this would
>>>> allow the Rex metadata to be attached to a otherwise normal field,
>> but
>>>> would only be understood and handled by the simulator if you had the
>>>> modular rex components installed.
>>>>> Another example might be tagging keywords for search and indexing
>>>> purposes, AI, etc. All the metadata properties would be accessible
>> from
>>>> region modules and they can write and add new ones relatively easily
>>>> under the proposal. (Just grab the SOG/SOP, then edit the metadata
>>>> dictionary).
>>>>> Thoughts?
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>> --
>>>> ---
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>> --
>> justincc
>> Justin Clark-Casey
>> http://justincc.wordpress.com
>> _______________________________________________
>> 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
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com