AWG flows login

From Second Life Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

AWG Login strawman

This is a strawman flow for first contact to rezzed avatar. It is very much a rough cut, work in progress, choose your favorite words to indicate raw, unfinished, proto work.

We will describe two sub cases. One with the agent host coordinating, one with the client in control. Note that the calls made are similar, the locus of control merely changes.


  • Components
    • User Client
    • Initial Authentication and profile Service: SecundusVita
    • Agent Domain host
    • Presence Management service
    • Public Asset Host Public_asset_host_a
    • Public Asset Host Public_asset_host_b
    • Private asset Host Private_asset_host_p
    • Simulator host JoesDiner

See also Second_Life_Login_API_Strawman

Sequence

  1. Initial login

The client contacts a well known hosting server, "SecundsVita" and passes in it's login information. The client receives back, a set of annotated services and properties which represent the services the client will contact in the next steps. This includes:

    1. The capability form of the login service for the agent domain host for the avatar

In order to pass this capability, the hosting server must perform several subordinate flows

      1. locate agent host for avatar

This will cause a lookup to be done, which will return the service hosts desired server for the agent host

      1. Create hosting capability

This is a call on the agent host, which causes it to create and return a capability for the client to use when contacting the agent host. (Note this nicely secures the connection)

    1. A set of properties about the avatar (enumerating where the avatars assets are stored, the last sim the avatar was in, the home sim of the avatar... )
  1. Agent domain login
  2. The client uses the capability acquired in step X to connect to the agent host. It passes the properties from step X, along with any additional ones it cares to add.

The agent host then performs a set of steps to get the agent populated and ready to use

(Two paths here. We pass the properties up, or the agent domain fetches them, I think I prefer the client passing them up, but I can be had on doing it elsewise.) The agent host gets assets

    1. presence host, post login agent credentials X, no location
    2. Public_asset_host A, get current agent state (stored set of assets defining the agent's appearence, etc)
    3. Public_asset_host A, Get asset list for agent credentials X
    4. public_asset_host B, get asset list for agent credentials X
    5. private_asset_host P, get asset list for agent credentials X

The agent host stores the assets lists and, possibly, signals the client to begin downloading themm

The agent host contacts the sim requested by the client (we'll assume, last, home, or specified, similar to SL today)

    1. Sim54, request agent arrival, agent credentials X, location X,Y,Z (returns a capability to the agent proxy on the sim, if allowed)
    2. Agent host passes the capability to the client
    3. Sim54//capability, Rez Agent, AssetList (Returns, X,Y,Z of agent)
    4. presence host, post agent rez, Sim, X,Y,Z