User:Zha Ewry/Scoping

Scope of the AWG's work

One topic which has come up repeatedly, is the scope of the AWG's work. In particular, there have been many words expended on the question of the current SL client, current SL simulator hosts, and similar components in the system. This article is an attempt to put some structure and scope around the AWG's work effort.

The assertion, is, that the architecture is going to be a set of web specifications which define how to build a web scale deployment of collaborative 3d spaces, on the overall model of second Life's current virtual world.

One way to define the scope of the project is by its work products. In particular, the normative, definitional work products which define conformance to the architecture, and the informative work products which inform the architecture, explain it, and often drive it, but are not part of its formal specification.

Normative work products

Here is a tentative list of the definitional, normative work products

1. A core model with highly scalable resources and mechanisms. This model is core, normative and primary because:
   1. it is prescriptive on the highly central goal of "Making the grid a scalable place"
   2. it is prescriptive on addressing the motivators expressed in Project Motivation
   3. it provides the single most important constraint for all other normative work products
2. The core REST web services plumbing, including c-http, the escrow pattern, and a publish/subscribe pattern for continuing messages
   1. prescriptive by fiat: worldwide use shows this approach has numerous benefits, ride on the shoulders of giants
   2. prescriptive by internal experience of suitability for Second Life architecture, and consistent with need for evolution
3. A set of web services define in terms of 2

   • implied

4. A set of messages sent as a result of an invocation of one of the web services in 2 and 3

   • implied

5. A set of interaction patterns using the services defined in 2, 3 and 4 to achieve specific effects

   • implied, and the non-specific parts cannot be normative

6. A set of things we find which exist which we cannot describe through items 2-5

   • How can you have an undefined normative work product????

Informative work products

Here is a tentative, less complete list of informative work products

1. A set of detailed use cases describing the requirements of the architecture
2. A set of scalability and interoperability analysis, informing the normative documents
3. A set of pluggable components and plug points. (Note most of these happen *inside* components, but matter)
   1. Physics engines
   2. Object Rendering schemes
   3. Authentication mechanisms
   4. add as needed
4. Use patterns for non normative (not defined as public services) common utilities
   1. Private asset stores (internal to clients, or co-located on client boxes)
   2. Private local sims (internal to clients, or co-located on client boxes, and not publically accessible)
5. Profiles, describing useful, coherent subsets of the services and optional pluggable components
   1. This cluster of services defines a "Linden Style Agent Domain"
   2. This cluster of services and pluggable components defines a "Linden Style region Simulator"
   3. This cluster of services defines a Linden Style Asset service
6. A set of reference implementations of any or all items in the normative work product set, such as:
   1. Reference implementation(s) of a specific service
   2. Reference implementation(s) of a specific profile
7. More?

Out of scope things

Here is a list of things which I think are not our business at all:

1. The internal implementation of any component, behind the defined normative work products from the first list
2. More?

- Zha Tuesday, October 9, 2007, 10:28 PM PDT

Zha Ewry Added Profiles, and Reference Implementations, October 10, 2007, 8:36 AM PDT