[Opensim-dev] Creator information preserved + 2 questions

[Melanie]

Hi,

my $.02 is that people should move forward, not back, and that 0.6.x
should die. I don't see any reason to write out old formats and
certainly see no reason to hang on to .net serialization.

YMMV

Melanie

Diva Canto wrote:
> 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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>