[Opensim-dev] Creator information preserved + 2 questions

[Diva Canto]

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