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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
