User talk:Dzonatas Sol/AWG Asset: Difference between revisions

From Second Life Wiki
Jump to navigation Jump to search
← Older editNewer edit →
mNo edit summary
Zha Ewry (talk | contribs)
135 edits
Keep common topics on one page, prevent wiki sprawl
Line 1: Line 1:
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.
Content moved to common asset talk page to prevent wiki sprawl, per [[Editing Guildlines]]
 
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.
 
*** -- [[User:Argent Stonecutter|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]])
 
*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)
 
What benefit do you get by using only a UUID inside the domain?  It seems like it'd be simpler to just use a unique URL as the identifier all the time.  I guess you can save on bytes if the uuid->url translation is trivial, but why bother?  That way you don't have to check to see whether the asset is in-domain and thus have to apply the transformation, or out-of-domain and thus do not.  Admittedly, debating this point is sort of icing-on-a-tea-crumpet, but, hell, I'd be in favor of moving Second Life's internals to use all urls, all the time.
 
Also, I do not understand what all this 'alluding' means.  Refers to?  Contains a url for?
*** [[User:Which Linden|Which Linden]] 22:52, 23 October 2007 (PDT)
 
Ah, I see where that can get confused about the URL. It is within the Asset's database record that appears bit more of an implementational detail to also store the URL. Given a potential 3rd normal form, one would not store the URL along with the asset unless the URL is part of the IP. I don't totally disagree, but I do question if the identity property of the asset record needs to hold more than a UUID for at least this cycle of the model to design. It still remains abstract enough to allow something other than only a UUID. I've heard hints about the "icing" (I've even suggested similar), and I surely don't want to obstruct the possibility. =)
 
"Alludes" or an "allusion" is less constrained than being "referred to" (a direct mention), while an allusion is more indirect, like passed by reference. An allusion may evaluate to an object, but the actual reference may be indeterminate by the value of the allusion alone. In implementation (discretely), an object can only make direct reference to other objects, but the structure of the references creates the allusion. For example, an oxygen atom and two hydrogen atoms can directly link to each other, but that linked structure alludes to a discrete molecule. It is too simple of a concept in order for it to be patentable, unlike many popular aspect-oriented languages that can be patented. =)
 
*** [[User:Dzonatas Sol|Dzonatas Sol]] 07:40, 24 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?
 
*** [[User:Dzonatas Sol|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. [[User:Dzonatas Sol|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. [[User:Dzonatas Sol|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. [[User:Dzonatas Sol|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 {{AWG|Region Domain}}, {{AWG|Agent Domain}}, and even the components of those domains, like {{AWG|Region Store}}s or {{AWG|Agent Store}}s.
 
*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:39, 23 October 2007 (PDT)

Revision as of 08:06, 24 October 2007

Content moved to common asset talk page to prevent wiki sprawl, per Editing Guildlines

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User_talk:Dzonatas_Sol/AWG_Asset&oldid=37968"