Multi-Process Client VAG -- draft

1. This is a pre-draft of the draft

This is an early draft so scope and focus are still fairly open. Please add comments to the Talk:Multi-Process Client VAG if you have slightly different concerns so that we can try to converge on a common viewpoint. This discussion could also expose other similar VAGs that are needed in this area.

Purpose

The Multi-Process Client Viewpoint Advocacy Group exists to provide input to the overall system archtecture design process in those areas where client-side functionality needs to evolve to track server-side changes.

More specifically, the Multi-Process Client VAG is concerned with identifying the key server-side changes that impact on the client, proposing at least one reference design for the client that can address all the expected changes, and assisting with the design and implementation of such a reference client. This work is expected to generate feedback in the opposite direction as well: a range of client-based Use_Cases will be examined in this VAG and used to generate requirements for the system architecture, particularly in the areas of scalability and interoperability.

As is evident from its name, this Multi-Process Client VAG has predefined one specific aspect of the required client, namely the change from the monolithic process structure of the original Linden client to a multi-process one. This will be discussed and justified in detail below, but it is not exclusionary: other client-oriented viewpoint groups may proceed along different lines.

This is a technical VAG.

See the Architecture Working Group and the Viewpoint Advocacy Groups for more information.

Areas addressed by this viewpoint

• Server-side APIs visible from the client.
• Scalability of the combined client and server systems from a client-side perspective.
• Interoperability of grids and worlds from a client-side perspective.
• Client diversity and its impact on client structure.
• Designing clients for extensibility.
• Use of clients as test tools.
• Harnessing the power of community for rapid client evolution.

Areas not addressed by this viewpoint

• Server-side details that are not visible from the client.

Multi-Process Client VAG Glossary

List of common terms specific to this VAG:

This section may be factored out, or alternatively its subsection headings may be removed for index brevity once it has stabilized.

Viewer (deprecated)

See Architecture Working Group Glossary for terms not defined here.

Source of Viewpoint

No existing sources for this viewpoint have (yet) been sought. This viewpoint is however highly reusable, and therefore existing sources are very likely to exist and should be investigated.

General concerns addressed by this viewpoint

TBD

Specific concerns within this viewpoint

Here we define the specific concerns relevant to event scalability.

Rationale for a Multi-Process Client

The original SL client performs its intended role as a fixed-function viewer for the self-contained Second Life service reasonably well, but it does not meet the requirements of a platform client, for the following reasons:

1. The platform view of an extended, highly scalable, and widely interoperable Second Life embraces third-party worlds, grids, assets, and contributions, which implies client diversity and flexibility.
2. The fixed functions of the original client represent only a small subset of the functions envisaged for that extended platform.
3. Many Limited Capability Clients (LCCs) will have hardware constraints which will make them unable to run the original client, for example cellphones.
4. Many LCCs will have user-interface constraints which require a radically different client structure, for example portable audio-only clients.
5. The monolithic structure of the original client does not allow wholesale omission of large and inappropriate subsystems (at best, the capabilities can only be disabled).
6. The original client does not support user choice of local facilities unless they have been pre-defined by Linden Labs. This is inappropriate in a platform client that needs to interoperate with third-party systems and assets.
7. Any change of facilities outside of those envisaged by Linden Labs for the specific Second Life service would require a complete client rebuild and release. The manpower implications of this alone would would be immense, let alone the impact on client stability and interoperability.
8. The monolithic client is a very large and complex application. Large and complex applications run counter to good software engineering practice, for numerous well proven reasons.
9. Monolithic clients cannot make good use of the new generation of multicore CPUs unless they are extensively threaded internally. Such threading can be very successful, but in general hardwires the client-side architecture to a fixed multithreading structure and very often leads to development restrictions. In addition, the lack of thread address space separation in a threaded application tends to reduce stability and harms resilience.

The above concerns are addressed quite effectively in a multi-process client architecture, as follows:

1. Match up above items in this section

Organization

Joining

Anyone with an interest in this Viewpoint is welcome to join. You should join the AW_Groupies group in Second Life.

In world meetings

This group is currently active on a continuous basis, communicating over group and friend/calling-card IM and via wiki. We will also endeavor to meet at least once a week in-world, or more frequently if desired.

Members are active on the wiki and in the SLDEV mailing list.

Meetings Schedule:

Meeting Agendas

• TBD

Chat Logs

• TBD

Architectural Descriptions/Views used to express this viewpoint

This VAG expresses a client-oriented viewpoint, and hence is concerned only with those Architectural Descriptions/Views that impact on the client. This section identifies:

1. the general form or representation of ADVs required to express the viewpoint of this VAG
2. the elements within such ADVs which will be used to express the viewpoint
3. how these elements within such ADVs map to the concerns of this viewpoint
4. the traceability to viewpoint concerns required for conformance with the viewpoint.

None decided.

Tools employed by this VAG

• Normal wiki textual and graphic representations are expected to be sufficient for this VAG.
• Programmed tools are expected to be developed for interface testing and performance measurement.

Members (Stakeholders)

Please note that the Multi-Process Client VAG is a non-hierarchical VAG in every respect, without exception. Any tags supplied with names are purely informational. Stakeholder ordering is alphabetical.

Morgaine Dinova 11:00, 7 November 2007 (PDT)

Saijanai Kuhn 11:00, 7 November 2007 (PDT)