Hi all,
I finally have the preservation of creator information working across
the board, except for IARs, which I'm still working on. By "preservation
of creator information" I mean the ability for preserving the origin
grid along with the user ID and name, both on archiving and on HG
transfers. Turns out that the main obstacle for this has been the .net
serialization that OpenSim has been using. For background and context,
see [1] and [2]. This email explains how things have taken shape and
asks for input on two technical details (one specifically from Justin).
Here's how it works.
For OARs, we can now save that information in the OAR files, and, upon
importing it somewhere else, the right information about the creator
will be displayed -- as opposed to the current behavior of always
assigning creator-ship to the estate owner where the OAR is imported. It
works like this:
$ save -profile=http://foogrid.org/user region.oar
This saves creator information for all scene objects that have a local
creator, that looks like this:
<CreatorData>http://foogrid.org/user/uuid;FirstName LastName</CreatorData>
Upon import to another grid, this information is associated with each
scene object, and stored persistently in the prims table. The URL (in
this case, http://foogrid.org/user/uuid) is meant to refer to a valid
service endpoint for the user's profile. Even if that endpoint is not
operational, the profile URL is useful, as it the basis for displaying
the origin of this user: the object's Creator field is shown to other
users as FirstName.LastName @foogrid.org.
A similar thing happens in HG transfers. (Plus there's a lot more to
come on transferring assets over the HG, but they are unrelated to this
email)
The two small technical issues are:
1) First, I'm now working in IARs, and have a question for Justin. I see
that UserInventoryItem deserialization is being done with a function
that imposes the most restrictive constraints on the external
representation. Specifically, it reads the representation sequentially,
assuming one and only one set of fields, in exactly one order. Is it ok
if I rewrite this as processing machine that is independent of the order
and can be extended to handle new fields, similar to what I have done
for SOPs? Any other things I should keep in mind, besides backward
compatibility?
2) Second, unfortunately .net serialization of flag fields has a
different behavior than .ToString(). If you have 2 flag values, .NET
writes them as "F1 F2" while ToString() writes them as "F1, F2".
Enum.Parse() expects commas. I've been debating about whether to
continue to drag the .NET behavior or to simply move away from it and
use the natural form for ToString and Parse. The tradeoff is wrt the
level of backwards compatibility. Although new versions of OpenSim can
handle both forms, old versions of OpenSim that still use .NET
serialization understand only the expected .NET format without commas.
We can generate the old form by giving the command line option
-version=0 on save oar.
So, technically, there is no issue. This is simply a usability issue, as
many people will not pay attention, even though there is a yellow
warning sign now on save oars warning people that they need to use
-version=0 to produce oars to be imported into older opensims. I'd like
to hear people's thoughts on this minor detail that is very annoying:
should we drag the .NET behavior into the future just because people
will miss the warning message? Or should we get rid of all traces of
.NET serialization and be insensitive to the people who don't read the
warnings? Any other ideas?
Diva / Crista
[1] https://lists.berlios.de/pipermail/opensim-dev/2010-October/009592.html
[2] http://opensimulator.org/wiki/Explicit_Object_Serialization
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
