THIS IS AN INCOMPLETE DRAFT

Introduction

Proposer: Justin Clark-Casey (justincc) Proposal Version: 0.1 Closing date for this proposal: 29th May 2009

The OpenSim_Archives (OAR) format appears to be a reasonably popular was of transferring whole regions between disconnected OpenSim instances (i.e. those which aren't in the same grid). An equivalent Inventory Archive (IAR) format is forthcoming that will allow disconnected transfer of inventory items and folders.

However, development of the IAR format has highlighted the issue of preserving creator information. At the moment, OARs only preserve this data if the creator in the target system has the same UUID as on the source system. If the creator has a different UUID or is not present at all, then on the target system it reverts to the 'master avatar' for that region (as defined in the region's configuration).

This problem has not yet been tackled in the OAR format since whole region transfer is a large operation and so has been confined to sophisticated users who can work around the non-preservation of creator data. However, it's likely to be much more of an issue with IARs since transferring individual objects between disconnected grids will be of utility to a greater number of people.

Therefore, I'm going to propose here an initial mechanism for preserving creator name information, which in the future can be extended to reference full profile data on remote systems.

This proposal is purely concerned with identity maintenance. It will not attempt any form of Digital Rights Management. Nor will it tackle licensing issues. This is not intended to prejudice any future development in those areas.

Creator id string storage

There are currently three places where creator information is stored in OpenSimulator. These are

1. In the item data stored in the inventoryitems table.
2. In the object data stored on a region in the primitems table.
3. In serialized object data stored in the assets table.

All three of these locations currently store creator UUIDs. I propose to change this so that arbitary strings can be stored as well as UUID strings.

For item and region data in SQLite and MySQL, creator id storage is already a char(36) field. This will need to be extended to a much larger or unbounded character field. I believe MSSQL uses a native uuid field. This will need to be changed to a string field.

For the serialized data, the automatic .NET serialization mechanism used currently wraps the creator id field in <UUID> tags. This will need to be changed. This may involve creating an explicit serialization format rather than an implicit one.

Alternative Approaches

An alternative approach to adapting the existing database and serialization Creator ID fields is to create a new parallel field, such as Extended Creator ID. This would store both uuid and non-uuid creator references, leaving the existing Creator ID field storing existing UUIDs only. Eventually, the original Creator ID field would be removed. This has the advantage of not breaking the 'contract' that the Creator ID field only store UUIDs.