User talk:Dzonatas Sol/AWG Asset

The identifier for an asset OUTSIDE a specific domain (trust domain, region domain, region, etcetera) is not a UUID, it's a URL. The form of the URL is unspecified, except that the host-part is the address of the asset server responsible for that asset, and that the asset can be manipulated with POST and GET commands passing standard URI-encoded parameters.

Within a domain the identifier of an asset is a UUID that is unique within that dmain and other domains sharing the same trust environment.

Assets hosted in other domains are mapped to UUIDs in a manner that is up to the domain. The expected technique is to create a new instance of the asset, containing a location property with the URI of the original asset, with all other properties copied from theoriginal, and with the asset data possibly cached in the local asset server.

• • • -- Argent Stonecutter 19:11, 23 October 2007 (PDT)

The inside/outside view of the identifier is true for what you say with and without the URL. The technique to create a new instance all depends on if the properties allow. A non-copiable tangible asset may have only a single instance in the entire grid, but there may be several referential assets to allude back to the single non-copiable instance. (See: #The Chair)

• • • Dzonatas Sol 19:31, 23 October 2007 (PDT)

The Chair

This where the "chair" question came about. What happens if the chair is made up of copiable and non-copiable assets where each piece of the chair being separate intellectual property and each IP owned individually by different people. Let's say the chair was manufactured by buying the seat separately from the base, and separately from the feet, and separately from the textures, so the chair then was assembled together by a person who bought all those pieces from different people. The assembled chair then is set to sell. How does one buy it? What are the steps to perform this? How does each step look in the databases for where each asset exists?

• • • Dzonatas Sol 19:31, 23 October 2007 (PDT)

Primary Database Thoughts

• In a decentralized system, there is always the potential net splits to occur. Methods need to be developed to prevent irrational assets or even broken referential assets. For example, one could require the complete form of an intellectual property be stored all in a single primary database with all related assets that constitute that form instead of being allowed to exist in multiple primary databases. Dzonatas Sol 23:07, 22 October 2007 (PDT)

• It is obvious that movement of tangible assets from one primary database to another primary database needs a cHTTP basis to communicate the move. Dzonatas Sol 23:07, 22 October 2007 (PDT)

• One way to avoid irrational assets is to allow secondary database be local to a primary database such that the secondary database stores abstract assets instead of the attempt to create irrational assets. I've done a similar scheme like this before on a very small scale, and I already know it is test cases with abstract assets are not as simple as to allow irrational assets. There are, however, less redundant sanity checks are needed with abstract assets locally to the primary database, and it reduces a load on the primary database with assets that would become tangible but actually remain transient. Dzonatas Sol 23:07, 22 October 2007 (PDT)

Domains

A domain is a group of hosts that may contain assets or instances of assets that share a trust model. They may be a trust domain (the largest contiguous set of hsost sharing a trust model), a region domain (from the original Linden documents), a single server. A uniform domain is one that shares a closer relationship than the AWG model specifies... the Linden grid is a homogenous domain. A non-uniform domain is one in which the AWG model must be used for interoperation between at least some members.

Within a uniform domain, assets are normally referred to using UUIDs.

Between uniform domains, assets are referred to using URLs. THe host part of the URL is the DNS address of the host responsible for that asset (eg, a region or an asset server). The path is unspecified, it merely has to be unique. URI-encoded attributes may be appended to request particular properties, iterate over properties, and (through POST operations) update properties. A standard URI for creating a new asset must be available on any asset host.

An asset may have multiple instances. Each instance contains a COPY of the asset properties that the requestor is allowed to have, a reference (location property) to the original asset, and possibly a cached copy of the asset data. When an instance is created from another instance, the location property of the original asset may be retained in the new instance, or the second instance may become a new independant copy of the asset with a permanent local copy of the asset data... that is, the distinction between instances and assets is flexible.

Details of enforcing intellectual property rights are primarily of interest for groups implementing non-uniform trust domains. Permissions and other rights metadata are only informational between trust domains. This is not to say that IP law does not apply, but that trust domains implementing different trust models can not be compelled to implement all trust models. It is anticipated that most domains will implement an asset property indicating that the asset is not to be transferred into another trust domain.

• • • - original content above from article space

This is good information. I like to see how this can be worked into other design documents such as Region Domain, Agent Domain, and even the components of those domains, like Region Stores or Agent Stores.

• • • Dzonatas Sol 19:39, 23 October 2007 (PDT)