OpenSim Profile Anchors
From OpenSimulator
m (Robot: Cosmetic changes) |
|||
| Line 4: | Line 4: | ||
{{proposal}} | {{proposal}} | ||
| − | =THIS IS AN INCOMPLETE DRAFT= | + | = THIS IS AN INCOMPLETE DRAFT = |
| − | =Status= | + | = Status = |
Now superseded by work done by Diva Canto. | Now superseded by work done by Diva Canto. | ||
| − | =Introduction= | + | = Introduction = |
'''Proposer:''' Justin Clark-Casey (justincc) | '''Proposer:''' Justin Clark-Casey (justincc) | ||
| Line 18: | Line 18: | ||
'''Closing date for this proposal:''' 29th May 2009 | '''Closing date for this proposal:''' 29th May 2009 | ||
| − | The [[ | + | 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. | + | 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. | + | 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. | + | 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 is called the OpenSim Profile Anchor format (OSPA). |
| − | This proposal is purely concerned with identity maintenance. | + | 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= | + | = Creator id string storage = |
| − | There are currently three places where creator information is stored in OpenSimulator. | + | There are currently three places where creator information is stored in OpenSimulator. These are |
# In the item data stored in the inventoryitems table. | # In the item data stored in the inventoryitems table. | ||
| Line 35: | Line 35: | ||
# In serialized object data stored in the assets table. | # In serialized object data stored in the assets table. | ||
| − | All three of these locations currently store creator UUIDs. | + | 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. | + | 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. | + | 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== | + | == 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. | + | 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. |
Revision as of 19:46, 3 March 2012
 |
Languages: |
|
|
|
This article or section is a Proposal It does not represent the current state of OpenSim, but is an idea for future work in OpenSim. Please feel free to update this page as part of the proposal discussion. |
THIS IS AN INCOMPLETE DRAFT
Status
Now superseded by work done by Diva Canto.
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 is called the OpenSim Profile Anchor format (OSPA).
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
- In the item data stored in the inventoryitems table.
- In the object data stored on a region in the primitems table.
- 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.
