OpenSim Profile Anchors - Revision history

MakoBot: Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

2012-03-04T06:50:40Z

Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

MakoBot: Robot: Cosmetic changes

2012-03-04T03:46:30Z

Robot: Cosmetic changes

Justincc at 22:07, 5 October 2011

2011-10-05T22:07:43Z

MakoBot: Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

2011-06-10T23:19:48Z

Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

Justincc at 14:37, 25 September 2009

2009-09-25T14:37:24Z

Ideia Boa at 09:58, 23 May 2009

2009-05-23T09:58:43Z

Justincc: /* Introduction */

2009-05-22T20:12:31Z

‎Introduction

Justincc: New page: {{proposal}} =THIS IS AN INCOMPLETE DRAFT= =Introduction= '''Proposer:''' Justin Clark-Casey (justincc) '''Proposal Version:''' 0.1 '''Closing date for this proposal:''' 29th May 2009 ...

2009-05-22T19:49:23Z

New page: {{proposal}} =THIS IS AN INCOMPLETE DRAFT= =Introduction= '''Proposer:''' Justin Clark-Casey (justincc) '''Proposal Version:''' 0.1 '''Closing date for this proposal:''' 29th May 2009 ...

New page

{{proposal}}

=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

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

@@ Line 18: / Line 18: @@
 '''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.
+The [[OpenSim Archives]] (OAR) format appears to be a reasonably popular was of transferring whole regions between disconnected OpenSimulator 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).
@@ Line 24: / Line 24: @@
 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).
+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 OpenSimulator 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.

← Older revision		Revision as of 22:07, 5 October 2011
Line 5:		Line 5:

	=THIS IS AN INCOMPLETE DRAFT=		=THIS IS AN INCOMPLETE DRAFT=
		+
		+	=Status=
		+
		+	Now superseded by work done by Diva Canto.

	=Introduction=		=Introduction=

@@ Line 1: / Line 1: @@
 __NOTOC__
-{{Template:Quicklinks}}
+{{Quicklinks}}
 {{proposal}}

← Older revision		Revision as of 09:58, 23 May 2009
Line 1:		Line 1:
		+	__NOTOC__
		+	{{Template:Quicklinks}}
		+
	{{proposal}}		{{proposal}}

@@ Line 4: / Line 4: @@
 {{proposal}}
-=THIS IS AN INCOMPLETE DRAFT=
+= THIS IS AN INCOMPLETE DRAFT =
-=Status=
+= Status =
 Now superseded by work done by Diva Canto.
-=Introduction=
+= Introduction =
 '''Proposer:''' Justin Clark-Casey (justincc)
@@ Line 18: / Line 18: @@
 '''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.
+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).
+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.
+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).
+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.
+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.  These are
+There are currently three places where creator information is stored in OpenSimulator. These are
 # In the item data stored in the inventoryitems table.
@@ Line 35: / Line 35: @@
 # 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.
+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 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.
+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.  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.
+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.