Talk:Second Life Grid Glossary

Where did the old content go?

Don't worry. Its all down below. In order to try and make this a little more focused I am putting in a section in here for each term and section in the glossary. This may make the page a little more usable. I suppose the next step would be a sub-page per term, but I am resisting that. Feel free to pull still current comments UP into the subsections. I'll try to grab some of that shortly, but. I think authors are probably better suited to that.

Asset

• (temp note): We need some clarity here, and elsewhere in the glossary between a Web Services description of resources such as an asset, and an in use description. If we view all assets as having URLs and a singular place in an asset server where the definitive copy of the asset exists, then we need to separate that from the potentially many places where copies of that set of information may be cached and used. -- Zha

• Ah.. Actually, if we wish to make a distinction between the asset's data, and its meta-data, then, we have the asset, which would be what we "get" from the URL, and the meta-data, which we seperate from the core item, in one of several ways. There was a nice bit of discussion of this in Zeros office hours on October 18 transcript -- Zha October 18, 2007, 5:42 PDT

• you meant Oct 18, i think. corrected to that effect Dr Scofield 03:18, 23 October 2007 (PDT)

• updated the asset entry. question: how does an asset reference come into existence? we need to get the flow for that. Dr Scofield 03:18, 23 October 2007 (PDT)

• asset is currently under discussion on sldev -- Dr Scofield 00:19, 18 October 2007 (PDT)

Heart, by your desire, fresh fantasy, deep and pure. You requested that I tell you the fantasy and how I feel. Not merely a description of it, but the deepest ways it impacts me. Therefore...

Transfered from another page, to ensure we are all on the same page

		Open Source Portal Learning the System Ways to Participate Architecture Working Group Design Documents
[edit/talk]   Description: Second Life Grid Glossary Talk:Second Life Grid Glossary/Description

Abstract Data Structure

Asset:

• Identity Property
• Intellectual Property
• Permissive Property
• Metadata

Specifications

• Note: The core asset-data is a form of intellectual property; however, one or more assets may allude to one or more combined forms of intellectual property. Another words, the abstractness allows for the one-to-one relation, one-to-many relation, many-to-one relation, and the more implicit many-to-many relation.

• The Agent Stores and the Region Stores are the primary databases for Assets, which have an Identity Property as the primary key, and that key is in a form of a UUID.

• Assets also exist in secondary databases, which perform similar to the primary databases. A cache for Assets is a secondary database.

• The properties and metadata provide the mechanism to access, cache, copy, modify, or distribute the Assets between databases.

• Each Asset has only one primary database such that there are never two or more primary databases for a given Asset.

• An Asset is tangible if it has a primary database.

• An Asset is transient if it has no primary database. For instance, an Asset originates from a secondary database.

• A tangible Asset that alludes to another tangible Asset is referential.

• A transient Asset that alludes to another Asset is abstract. Note: there a distinct difference between the abstract data type and an abstract Asset.

• A tangible Asset that alludes to a transient Asset is irrational. Note: irrational Assets create complex sanity checks for them to be rationalized if possible.

• An Asset pointer is not an Asset itself; it is merely a pointer to an Asset. Note: The Asset pointer is more implementational than architectural, but we specify it here so that any API design may use it.

Brainstorming

• allow objects to only be able to rez on certain regions (adds to the agent's restrictions)
• AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
• allow assets to be transferred between agent domains
• allow assets to be accessed from multiple agent domains
• allow truly distributed asset storage
• Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.
• allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.
• possibility to add proxies for assets. People running their own servers might want to reduce disk access on the sim machines by adding a second machine with a proxy. Proxies improve response time on webservers with heavy access a lot, so it should work for sims with high traffic, too.
• allow geometry standards to be used for objects. SL doesn't have a tool like Sketchup and so needs to be more open to other existing geometry creation tools (sculpties are too insufficient).
• It is likely that *no* geometry standards will ever be sufficient. Therefore, don't waste time on defining geometry standards. Instead, focus on designing a way of making the suite of available geometry standards extensible simply through a posteriori addition, without requiring a priori definition.

• It is possible to implement asset storage in a completely distributed way
  • Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
  • A completely Peer-to-Peer (P2P) storage protocol is possible

It's worth pointing out that P2P is the only topology that scales with the number of participants in the world. Other topologies have useful properties and get us part of the way (eg. private distributed authoritative world servers fronted by non-authoritative commercial big-iron caches), but ultimately P2P has no real challanger.

• • To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
    • Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
    • Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object). For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
    • Persistent: Some mechanism to control the lifetime of assets may be needed
      • Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
      • If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
      • What would happen to assets that remain accessible but never 'accessed' for long periods of time? (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
      • Will it be possible to delete assets/accounts someday?
  • This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
    • Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
• Assets should support being signed (and notarized)
  • Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
• Assets should be raw data.
  • Asset type, permissions, creator, watermark, etc would be meta-data.
  • Any kind of meta-data could be added and used or ignored as needed.
• How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
  • Would an upload fee make sense for transferring objects to different grids? Who will pay it? The creator? The first one who bought it and travels to the other grid?
  • If so, how would that fee be determined for a completed object?
  • Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?

Decentralized assets

• How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?
  • Local database backend stores all the local content, any content on the remote asset servers with appropriate permissions (perhaps a "can download" flag?) can be downloaded for use on a local stand-alone grid
  • Any new assets, or locally modified assets can be re-uploaded
  • "Can download" must imply "Can modify" for practical reasons (DRM will not work!)

More material brought onto the common page 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)

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?

• • • 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. =)

• • • 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?

• • • 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)

Avatar

Does the Avatar represent and agent, or a user? I think a user. The agent is a software construct which permits the user to interact with other portions of the system.

Domain

• I replaced the label of the link to "AWG Domain rationale discussion" by "Domain rationale discussion". The use of "AWG Domain" creates terrible confusion and also conflicts with LL's use of the term. The page itself should be renamed too, but that's better done by its creator. --Morgaine Dinova 09:49, 20 October 2007 (PDT)

• The architecture proposed by LL also created a point of confusion in its use of "Organization Domains" ... there's some sort of dimensional incompatibility there with the use of "Domain" in "Agent Domain" and "Region Domain". I wrote a little about this topic back in September when I looked at the diagrams from the first meeting. Organization is better thought of as an attribute within this architecture, because it is so orthogonal to the other domains. What's more, it's a composite attribute with many aspects: for example, a server could belong to company A, provide resources for the group B, and be located in colo C. Which is the Organization domain? There is no single answer. "Organization Domain" isn't a very cohesive concept. --Morgaine Dinova 10:11, 20 October 2007 (PDT)

Pre 10-19-2007 content

• The title needs changing to something less specific, like "Glossary", because Viewer is certainly not a component of a grid. --Morgaine Dinova 09:29, 25 September 2007 (PDT)

• Added Services and Utilities to the list -- Zha Ewry 9/26/2007

• I didn't want to define these since they reference the Linden "implementation" but it would be good to define what is meant by "Central Utilities" and Identity, location, and currency.--Burhop Piccard 17:55, 3 October 2007 (PDT)

• Page renaming

As has been discussed on various occasions in AWGroupies and elsewhere, the parent page Components and Roles has evolved, and as a result it is no longer named appropriately. I would change it to one of the names that have been suggested (eg. AWG_Glossary) if I knew how to migrate its namespace tree as a unit, ie. including Talk, history etc, but I don't know how to do that. Anyone? --Morgaine Dinova 02:32, 12 October 2007 (PDT)

• did that. refactored page into IEEE 1471 page and glossary page while i was at it. Dr Scofield 09:12, 12 October 2007 (PDT)

• Thanks, that's hugely better. :-) --Morgaine Dinova 03:57, 13 October 2007 (PDT)

• Reformatted page to use small '====' section headings instead of labels, so that we can edit them one at a time, more scalable. :P --Morgaine Dinova 03:57, 13 October 2007 (PDT)

• DrS, I've reexpressed your additions under "Architecture" as architectural descriptions for some randomly-named "message flow viewpoint" (maybe it should refer to protocols or whatever, change as required). The terms for "documents" are in flux --- ADV for "architectural descriptions and views" is just a placeholder, although it seems to work well. Zero has already delivered those nice graphic ADVs that cover 2 or 3 different viewpoints, although the concerns aren't all that easy to identify in them precisely because they're all thrown in together.

The central idea (as in IEEE-1471, which is a synthesis of a billion approaches prevalent in industry), is that "The Architecture" doesn't in fact exist outside of our heads, and is only communicated in specialised views which reflect the concerns and bias of specific parties.

I am forced to admit that I find the bullet point above, simply, at some level incomprehensible. The architecture we are defining is not some platonic ideal. It is a set of formal, normative specifications which to the best of our human capacities specify precisely and unambiguously how to build a conformant implementation. The specifications, hold no viewpoint, they have no biases. They may result from the fusion of many viewpoints, the clash and resolution of many stakeholders, but the architecture is deeply and fundamentally the normative documents which define it and nothing else. Reifications and realizations of the architecture may deviate from the specifications, but that doesn't change the architecture at all. - Zha

• That's not how the industry sees it Zha. The viewpoint-based approach of IEEE-1471 isn't something radical and new, it's just a distillation (and a very simple non-prescriptive one) of many standard approaches to defining architecture in use throughout computing. Even Zero has effectively used this method in his architectural diagrams, which express the architecture from 2 or 3 different viewpoints. There is actually no other way, no matter how hard you try: your document will always end up describing how the architecture addresses the concerns of a given viewpoint. If you claim that your "normative documents" cover everything salient in the architecture, then all you've done is put all those viewpoint-based descriptions together in one lump. You're not really disagreeing. :-) --Morgaine Dinova 00:32, 14 October 2007 (PDT)

• More importantly though, it allows us all to work separately/grouped but towards a common goal, instead of bickering about what should appear on a one single central document. And an added benefit: it can make it easier for LL to back-port ideas into SL1, since the concerns and solutions will be nicely factored out. Evolution is an important goal, as Zero has made clear. --Morgaine Dinova 00:41, 14 October 2007 (PDT)

• I added a use case defintion as used with AWG. A "use case" is a bit different since its not really part of the architecture but one of several tools for coming up with an architecture. I still think it goes here because I've tried to narrow the definition a little bit to the AWG context and avoid some of the common misuses of the term. --Burhop Piccard 15:17, 15 October 2007 (PDT)

• Very useful, as we bandy this term around a lot. :-) It begs for a definition of "user" now, and I can't find a useful one. --Morgaine Dinova 21:28, 15 October 2007 (PDT)
• I removed the first external link, to Wikipedia, as it widened the possible meanings rather than narrowing them. The whole point of this AWG glossary is to make us all speak the same language, as the Tower of Babel effect was leading to some unnecessary arguments. External links act in the opposite direction in this case. I left in your second Wikipedia reference, but I don't think that that line helps at all, as it just says "throw in the kitchen sink". If you could revise the line to not need the link, that would be helpful. :-) Perhaps follow the form you set in minimal template and add a detailed template? --Morgaine Dinova 21:58, 15 October 2007 (PDT)

Yes, I'd like to create a final state template but its a bit trickier as it needs to be more tailored to the system. I don't think the link is really needed except as a reference for people wanting more information. I'll try to reword it. --Burhop Piccard 09:35, 17 October 2007 (PDT)

• Zha, excellent addition to architecture: you've reconciled the differences through "point in time". Works for me. :-) --Morgaine Dinova 21:28, 15 October 2007 (PDT)

• I added the "domain" term but I don't think its quite right. Can someone with a better understanding update it? --Burhop Piccard 11:09, 16 October 2007 (PDT)

• In general, skimming the glossary, it feels like we need to get a little more disciplined about how we toss around phrases. For example, "meta data" is defined in a way that only refers to meta data on assets. There are other places in the architecture where we might well want to talk about meta-data, and in fact, depending on exactly how we define and use asset, the meta-data, may or may not always be attached to the asset. Other examples which concern me are resource, where we provide an extremely scalabality centric perspective on resource, which, for example, ignores the common web notion of a resource. We describe, Identity as both an utility and a component. We describe one specific domain, and describe it, in fact in a way which contradicts Zero's diagram, which has two seperate regions domains, both operated by Linden Labs.

I can just go in and start hacking on these, but, I'm hoping the people who posted them will take a careful look at them first. -Zha 7:59 pm PDT, October 17, 2007