Difference between revisions of "User:Dzonatas Sol/AWG Asset"

From Second Life Wiki
Jump to navigation Jump to search
m (AWG Asset moved to User:Dzonatas Sol/AWG Asset: moving to user space for now)
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
* An entity which can be transferred from agent to agent or from agent to region or from region to agent. It can be something like an object, texture, sound, link, landmark, and so forth.
{{:AWG/PageHeader}}
: Architecturally, an asset consists of '''asset properties''' and '''asset data''' (also called meta data).
::* (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.'' -- [[user:Zha Ewry|Zha]]
::* ''asset is currently under discussion on sldev'' -- [[User:Dr Scofield|Dr Scofield]] 00:19, 18 October 2007 (PDT)


* Assets exist in the {{AWG|Agent Stores}} of the {{AWG|Agent Domain}} or in the {{AWG|Region Stores}} of the {{AWG|Region Domain}}.


Is this statement about assets true? It is almost certainly incomplete. Assets are stored in asset servers, and their persistent, authoritative state probably resides there. Further, this definition refers to two terms, neither of which has been introduced before. (Agent stores and region stores) If an asset exists in multiple places, which is definitive, and which is a copy? If this is an attempt to capture the fact that some portion of an asset is likely to be used within components in the agent and region domains, then, we need a use case which exposes a need for an addressable  component of the architecture which lives in these domains ans stores architecturally addressable items. If, this represents  suspicion that we will use such items inside of components in those domains, then it is probably out of scope for the architecture. 


We need to pay close attention to the separation between artifacts which we need to expose as part of the architecture and artifacts which will naturally exit in components of the architecture. This isn't to dismiss the importance of those artifacts, but to highlight the need to be clear as to what is the basis for  inter operation and the definition of components, and what is the business of components within that architecture. - [[User:Zha Ewry|Zha]] 16:47 PDT October 18, 2007
= Abstract Data Structure =
== Brainstorming ==
 
{{AWG|Asset}}:
* {{AWG|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 {{AWG|Agent Store}}s and the {{AWG|Region Store}}s are the primary databases for {{AWG|Asset}}s, which have an {{AWG|Identity}} Property as the primary key, and that key is in a form of a UUID.
 
* {{AWG|Asset}}s also exist in secondary databases, which perform similar to the primary databases. A cache for {{AWG|Asset}}s is a secondary database.
 
* The properties and metadata provide the mechanism to access, cache, copy, modify, or distribute the {{AWG|Asset}}s between databases.
 
* Each {{AWG|Asset}} has only one primary database such that there are never two or more primary databases for a given {{AWG|Asset}}.
 
* An {{AWG|Asset}} is '''tangible''' if it has a primary database.
 
* An {{AWG|Asset}} is '''transient''' if it has no primary database. For instance, an {{AWG|Asset}} originates from a secondary database.
 
* A '''tangible {{AWG|Asset}}''' that alludes to another '''tangible {{AWG|Asset}}''' is '''referential'''.
 
* A '''transient {{AWG|Asset}}''' that alludes to another {{AWG|Asset}} is '''abstract'''. Note: there a distinct difference between the abstract data type and an abstract {{AWG|Asset}}.
 
* A '''tangible {{AWG|Asset}}''' that alludes to a '''transient {{AWG|Asset}}''' is '''irrational'''. Note: irrational {{AWG|Asset}}s create complex sanity checks for them to be rationalized if possible.
 
* An '''{{AWG|Asset}} pointer''' is not an {{AWG|Asset}} itself; it is merely a pointer to an {{AWG|Asset}}. Note: The {{AWG|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)
* allow objects to only be able to rez on certain regions (adds to the agent's restrictions)

Latest revision as of 16:25, 6 November 2007

Slarch.jpg

 Description:

Dzonatas Sol/AWG Asset

An Asset is an abstract data type, which is a set of properties and metadata that provides the mechanism to access a form of intellectual property.


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