[Opensim-dev] .net serialization of SOGs

Sun Oct 10 19:03:07 UTC 2010

I believe the decision was made that way because we didn't want to
keep lugging the packets and sl protocol handling around.

Thee will be a day when SL and LLUDP are a faint memory and OpenSim
should still be there. So the core should not depend on a lib that
contains LLUDP and the packets.

Maybe OMV needs to be broken up further. Maybe, instead of breaking
out the thigns we DO want to keep, they should break out the LLUDP
into a separate lib that can then be dropped eventually.

I haven't studied recent libOMV versions so I can't say anything
about the feasibility of that.
I do know that we need to be able to modify our own stuff without
delay, so copy/paste for this crucial part of opensim seems to be in
order.

Melanie

diva at metaverseink.com wrote:
> Currently, OpenSim.Region.Framework depends very much on libomv's 
> serialization facilities. The Uuid gatherer, for example, uses the 
> decode() methods to sniff UUIDs.
> 
> OK, well, I'm going to port some code from libomv into OpenSim so that I 
> can get going on this, but honestly I think this is silly. We should 
> consider some other alternative. I'm a strong +1 on a library that 
> defines Asset types and their [various] serializations, independent of 
> who uses such library.
> 
> It's true that libomv is/was focused on the Linden asset types & 
> formats, but many/all of those asset types make sense in general, even 
> if their external representations are completely different than the ones 
> used by the Linden viewer (notecards, gestures, etc).
> 
> 
> On 10/10/2010 11:02 AM, Melanie wrote:
>> Well, we should just migrate it back. Not the whole shebang, only
>> what we need.
>>
>> It was a stated goal, from way back, that OpenSim should be able to
>> run without OpenMetaverse.dll if the Linden client code is removed.
>>
>> That is why OpenMetaverse.Types.dll exists. It is the one that we
>> decided we would keep relying on, but OpenMetaverse.dll should, so
>> it was decided, eventually only be referenced by the LL client stack.
>>
>> If we want to change that policy, we'd have to have a core vote, as
>> it was also a core vote that established it, iirc.
>>
>> Melanie
>>
>> diva at metaverseink.com wrote:
>>> 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
>>>>
>>> _______________________________________________
>>> 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
> 
> 