Difference between revisions of "SLGOGP Draft 1/Discuss 1-1 Domains"
m |
(discussion of issues that I've come across while attempting to follow the SLOGOP format for documentation) |
||
| Line 12: | Line 12: | ||
: 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. [[User:Morgaine Dinova|Morgaine Dinova]] 21:42, 11 March 2008 (PDT) | : 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. [[User:Morgaine Dinova|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 1) se 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. [[User:Saijanai Kuhn|Saijanai]] 16:06, 31 March 2008 (PDT) | |||
Revision as of 15:06, 31 March 2008
| SLGOGP Draft 1 > Discuss 1-1 Domains |
 | This is a talk page. Please sign comments you leave here by putting four tildes (~~~~) at the end of your comment. You might also prefer to click on "Add Topic" to create a visually more pleasing discussion style. For more guidelines, see Talk Page Guidelines. |
- 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 1) se 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)