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 > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
