[Opensim-dev] Creator information preserved + 2 questions

[Justin Clark-Casey]

On 26/11/10 19:03, 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).

I'm impressed you found [2], that was written way back in June 2009 when I was thinking about the same problem. 
Unfortunately, I had to abandon that attempt due to changing priorities.  Congratulations for getting the work done.

>
> 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)

If you don't put in a profile is the name still preserved?

>
> 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?

I think that's fine and makes a lot of sense.

By the way, I'm already writing out an older version of extended creator data in item.CreatorId (the OSP stuff).  But I 
never got to the point of preserving the user name unless it was already present on the target OpenSim.  I imagine that 
this should continue to be backward compatible with your improved system if the new data is going in a different field, 
which would be very cool.

>
> 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?

I appreciate the neatness of just using ToString().  However, if we write out the space separated format then people can 
produce one OAR that can be loaded both on OpenSim 0.7.1 (and take advantage of the extended creator data) but still be 
loaded on OpenSim 0.7.0.2 and earlier.

Otherwise, the OAR/IAR creator won't need to create 2 copies of everything they produce, one for loading on OpenSim 
0.7.0.2 and before and one for loading on 0.7.1 (if they want to take advantage of extended creator data).  I expect 
that people publishing OARs/IARs will do this since they want it to be available to as many people as possible. 
Naturally, this would be a big hassle.

Equally, I would side with the argument that there would be less confusion over mysterious error messages (since OpenSim 
0.6.9 and 0.7.0.2 don't check the OAR version before trying to load data).

>
> 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
>


-- 
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc