Difference between revisions of "AWG Use Cases"
Gigs Taggart (talk | contribs) (strategic scope) |
Gigs Taggart (talk | contribs) |
||
Line 15: | Line 15: | ||
* Provide for availability of continuous and portable identity across all domains | * Provide for availability of continuous and portable identity across all domains | ||
* Preserve the micropayment economy (??) | * Preserve the micropayment economy (??) | ||
* Create a system that will scale to 500 million active users with | * Create a system that will scale to 500 million active users with 500 thousand regions | ||
==System Scope== | ==System Scope== |
Revision as of 15:37, 17 September 2007
This page will hold all sorts of use cases and should be some brainstorming place. Please add use cases in the form "<Role> <Action>" like "User logs in". If it's a requirement such as "The system needs to support OpenID" write it like that. For now we should aim at one-line descriptions for an overview. For more detailed explanations make the use case a link and explain it there.
Use Cases of the existing system should be marked with an (*) for now. Areas of potential discussion are marked with (??)
Use Case Capturing
We use the defined Roles and Components. "User" refers to an so far undefined entity. This might be some web service client querying for data.
Strategic Scope
- Allow private grids with varying levels of autonomy
- Allow very small scale operation of regions, such as home users
- Preserve the current level of DRM that is provided (??)
- Provide for availability of continuous and portable identity across all domains
- Preserve the micropayment economy (??)
- Create a system that will scale to 500 million active users with 500 thousand regions
System Scope
The use cases below are system scope
- User creates a new identity (*)
- User updated identity (*)
- User deletes identity (*)
- User retrieves identity information (*)
- User adds a verification method to an identity (age, real name, financial, part of a company, ...)
Administrative Use Cases
- Administrative User creates a new agent (*)
- Administrative User deletes an agent (*)
- Administrative User edits an agent profile (*)
- Administrative User "governs" an agent (*)
- Ban
- Kick
- CSR Actions
Information Use Cases
- User retrieves profile information about an agent (*)
- User retrieves identity information about an agent (age, RL info, what about permissions here?)
- User retrieves presence (online) information about an agent (*)
Basic Use Cases
- Agent logs in (*)
- Agent logs out (*)
- Agent sends an instant message to a user (*)
- Agent says something on public chat (*)
Inventory Use Cases
- return inventory for an agent
- store inventory for an agent
- Manipulate Inventory
- Move/Copy items/folders (*)
- Delete items/folders (*)
- Rename items/folders (*)
- Share items/folders
- Agent rez's something in a Region (*)
- User subdivides land within a region (*)
- Administrative User retrieves debugging information from a region
- Script Activity (*)
- Physics Activity (*)
- Agent Activity
- Statistics (*)
- Administrative User manipulates Access Control List (*)
Some possible futuristic scenarios
(add here what scenarios are completely different but maybe should still be possible with this new architecture. This is mainly to get our thinking broader. These can also be described by some bullet points and from these we should later on construct use cases).
EVE Online like setup
- regions are solar systems
- avatars do not (yet) exist and agents are represented by space ships (some sort of avatar)
- objects are planets, space stations, asteroids, etc.
- regions are connected by portals
- regions do not have a predefined size
- objects on regions are mostly fixed
- most of the transactions will be from agents to agents (might be bots)
Earth & Beyond like setup
- both space and land regions
- avatars exist on land regions (in E&B it was only stations)
- space and land regions connected by a station portal
- space regions connected by warp portals
- space features simliar to EVE Online setup
Corporate subgrid setup
In this scenario e.g. corporate entities might want to have their own protected subgrid for only their controlled agents but these agents might still be allowed into a more public grid. This might also need to support:
- a means of defining on which region a particular object from a particular agent is allowed to be rezzed (agent needs to not be allowed by agent provider to rez certain agents on public regions. A region might also want to define objects from which agents are allowed to be rezzed).
- a means of defining who is allowed on which region from the region point of view (e.g. the corporate grid does not allow public agents)
- a means of defining who is allowed on which region from the agent point of view (e.g. the public grid does not allow corporate agents or agents it does not know about)
Google Earth like setup
- There are layers of objects/information on one defined region (=earth)
- A viewer can decide which layers to load/show
- Agents do not necessarily be represented in a region
- one could think of these layers as layered regions maybe