SLGOGP Draft 1/Discuss 1-1 Domains

the sentence "The viewer does so from the vantage point of an agent. An agent is persistent identity and persona that interacts in a virtual world. The agent persists and can be interacted with even when the user controlling it (though a viewer) is off-line." might need some clarification in what sort of interactions are meant here. Inventory transfers and the like? [Tao Takashi]

"The agent persists and can be interacted with even when the user controlling it (though a viewer) is off-line.":

This has surprised many of us, as up to now the prevailing notion had been that the agent comes into being (based on data in account records) when the client connects, and disappears when the client disconnects. If (conceptually) the agent is now seen as persisting so that off-line operations can still be viewed as interacting with the agent, then

the distinction between agent and account has been lost,
the clean interpretation of agent as a proxy for the client has been lost,
agent now has two different states, and on-line and an off-line one.

This new definition of agent as a persistent entity seems to bring more trouble than benefit.

If the reason for the change was that you seek the symmetry of all off-line operations being performed in the Agent Domain, then a cleaner approach to this would be to instantiate the agent whenever an off-line operation is effected. Since this matches what actually happens, and since keeping agents instantiated regardless of login status has dreadful scalability, the cleaner approach also reflects the design of non-toy implementations, which is no bad thing. Morgaine Dinova 21:42, 11 March 2008 (PDT)

On the subject of the nuts and bolts of how things are documented, I've been working with Tess to get the rez_avatar portion of the strawman login API put into a form suitable for inclusion with SLGOGP: https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Rez_Avatar_Capability I'm confused concerning how server to server interactions are shown distinct from the viewer to server interactions. I suppose that this distinction is inherent in what kind of URL/capability is being discussed, but it seems to me that we should make it clear in the table, and regardless, we should make it clear in the description and/or naming conventions. You will note that I'm a little vague on how to name the rez_avatar region host URL. I don't even know if its a capability. These kinds of details need to be ironed out.

I've also been looking at how UML is used in protocol descriptions. There's no real use of sequence diagrams with the long-poll strategy that I can find anywhere on the interent, so we'll need to devise our own convention there, I think, if we use more or less formal UML diagramming. Saijanai 16:06, 31 March 2008 (PDT)

Reading through the draft I can't help notice the conspicuous absence of reference to assets. I am assuming that asset storage is linked to the agent domain, but if so it isn't mentioned. Perhaps it is actually considered part of the region domain?—since that's where content is actually created by an agent (e.g. interactively). I think something should be mentioned about the asset storage service and how it relates to the other components—as they're obviously an important part of any grid. From my understanding of the SL grid, the asset storage system is a custom and somewhat independent 'database' from the databases that store agent information, such as inventory.

Some points I'd like to see clarified in the document:

Is the intent for an agent domain to also provide access to asset content? (regardless of how it chooses to do that)
- If so, that implies that a region needs to go through the agent domain to obtain asset data, for example to rez an object for an agent
- How is asset IP controlled in this case? i.e. will a sim need to contact the agent domain of both the owner AND creator of an object (e.g. on rez)
  - As an object owner, if I have copy perm for an object, might I assume to be able to rezz it in any region domain to which I have access?
  - As a scripted object creator, I require control over which region domains my script bytecode can be allowed to reside in, irrespective of which region domains its current owner can be in (—to avoid encryption secrets embedded in script bytecode from being send to untrusted domains over untrusted networks)
If asset storage is instead linked with the region domain
- Does that imply inter-region-domain exchanges in order to rezz objects when I'm in a different region domain from the one the object was created in?
- What about attachments? Where do they execute? Currently, they execute in the sim where the agent is at any given moment, but again, script creators will require control over which region domains they trust to execute the bytecode in the attachments they create, independently of which region domains the attachment owner/wearer might trust.
  - If attachments execute in a special 'agent sim' (a sim just for running scripts in the agent's attachments) situated in the agent domain, that implies that the executing attachment scripts will need a two-way communication with the region/sim the wearer is currently in.

I realize that some of these issues may be beyond the intended scope of this document, but something needs to be said about the relationship of asset storage to the agent & region domains at least. My apologies if there are some answers in there I missed. Cenji 2008-05-07

Keep in mind that this part is ONLY concerning login itself and that the proposed protocol is very much an interim hack designed to to transition between the current way of doing things and a future, more robust and scalable way. Eventually Agent Domain WILL handle assets, but for now, all the agent domain really does is serve as a proxy between the sim and the viewer, obtaining data from the sim and passing it to the viewer in the same format that the viewer now gets directly from the sim. Here's a link to the "rez avatar" portion of the protocol, which is still being worked on: User:Saijanai_Kuhn/Rez_Avatar_Capability Saijanai 19:44, 12 May 2008 (PDT)