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
[email protected] 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,<[email protected]
<mailto:[email protected]>> 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
[email protected]<mailto:[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
