[Opensim-dev] .net serialization of SOGs

[diva at metaverseink.com]

And I can see the back and forth that has been going on :) libomv got 
some code from OpenSim.Framework.Serialization...

Would it be worth establishing a 3rd project for this? One where both 
the OpenSim devs and the libomv devs would have commit rights? So that 
we minimize this copy-paste-change back&forth...


On 10/10/2010 10:24 AM, diva at metaverseink.com wrote:
> I can see good arguments on both sides. On the one hand we (in OpenSim)
> need to have complete, and immediate control over this code, in order to
> be able to do things such as what I'm doing right now -- adding more
> information to those external data representations.
>
> On the other hand, control, in OpenSim, often comes with entanglement.
> SOG serialization, for example, is horribly tangled with Scenes at the
> moment, and that is a major block for fixing things like having the
> Library work as a service, etc. -- not to mention enabling 3rd party
> tools for manipulating content in a sane manner. So, in that sense, I
> really like the idea of having this code in a separate library, far away
> from OpenSim Scenes, which should merely be clients of such library.
>
> We have a place for it: OpenSim.Framework.Serialization. If we're to
> copy-paste-change libomv, I'll have to bring in the entire
> OpenMetaverse.Assets namespace, which is where all the serialization
> goodies are.
>
> Is there a middle ground?
>
> On 10/10/2010 8:30 AM, Melanie wrote:
>> Copy/Paste/Change please.
>>
>> it's been a discussed and stated goal to reduce use of OMV classes
>> not in the "Types" dll.
>> Making ourselves dependent on OMV code for something as critical as
>> this isn't right.
>> There are lots of fields that will need to be added, from simple
>> ones like sit data to complex ones like vehicle physics.
>>
>> Melanie
>>
>> diva at metaverseink.com wrote:
>>> After thinking about it, I think I know the way out of our dependence on
>>> .net serialization. I'm planning to do this [today], so if anyone has
>>> concerns, please speak up.
>>>
>>> The main problem with what we have is that the serialization is being
>>> done automagically by .net via reflection, leaving us completely out of
>>> the loop and at the mercy of the nasty .net serialization restrictions.
>>> So the smooth transition out of this is to reproduce the serialization
>>> strings that .net is producing, but via our own code. That will be stage
>>> 1, and will ensure 100% compatibility with the data that already exists.
>>> But that will give us the ground to then do the right things with
>>> serialization, like adding a MIME type and a version number to whatever
>>> is being serialized.
>>>
>>> Luckily jhurliman has already done most of it in libomv, probably as a
>>> consequence of him pulling his hair when he encountered the SOG
>>> serialization in OpenSim... I'm undecided on whether to reuse that code
>>> as-is or copy-paste-change it, since I'm planning to add more fields,
>>> and context, to the SOG serializations. Without getting into flame wars
>>> between OpenSim and libomv, any thoughts on this, from a pragmatic point
>>> of view?
>>>
>>>
>>> On 10/9/2010 12:39 PM, Dahlia Trimble wrote:
>>>> How about the various OSD serializations in libomv? They seem to be
>>>> pretty robust these days.
>>>>
>>>> On Sat, Oct 9, 2010 at 11:05 AM,<diva at metaverseink.com
>>>> <mailto:diva at metaverseink.com>> wrote:
>>>>
>>>> Dear devs,
>>>>
>>>> I'm pulling my hair here with the serialization of scene objects.
>>>> This is horrible! Using .Net serialization for something as
>>>> important as this is the worst idea ever. We're completely frozen.
>>>> I'm trying to add an additional field for the creator info, and I'm
>>>> stuck in all sorts of ways: I can't compute the value of that field
>>>> at serialization-time, and then there are the issues of
>>>> compatibility with previous versions of the SOP class.
>>>>
>>>> I'd like to understand all the implications of doing an entirely
>>>> different serialization procedure, one that does not use reflection,
>>>> and that allows for processing-during-serialization. What will
>>>> break, and therefore needs fixing?
>>>>
>>>> I understand all archiving related to previous versions will break,
>>>> so we need to keep supporting the existing serialization 'disease'
>>>> for the foreseeable future. I also understand that TPs/crossings
>>>> between sims that talk different SOG serializations will break, but
>>>> that's not so bad.
>>>>
>>>> Anything else I should be aware of before I go off and redo this?
>>>>
>>>> Diva / Crista
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de<mailto: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
>