Difference between revisions of "AWG Agent"

From Second Life Wiki
Jump to navigation Jump to search
(anothr section moved from Brainstorming to gather all the scattered ideas for easier organization/design)
 
(Replacing page with 'Merged into Agent discussion talk, to avoid wiki sprawl, per Editing Guidelines https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Agent')
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
* The envisaged [[Project_Motivation|massive scaling]] requires new forms of item organization, search, and access to cope with vast expansion.  The current inventory mechanism is already stretched right now, so this issue needs early design attention.
Merged into Agent discussion talk, to avoid wiki sprawl, per [[Editing Guidelines]]  
* it should be possible to manage inventories of all your agents under one identity. The idea is to e.g. being able to move items from one inventory to another
https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Agent
* some organisation providing agents should be able to define on which regions an agent is allowed to connect, what he/she can do with object in their inventory
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)
* it should be possible to import and export friends lists or groups of friends
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.
* an agent needs to provide various methods of verification
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains.
* Each agent needs to be able to define certain permissions on what other agents or groups of agents are allowed to see about him (online status, identity information, etc.)
 
==== possible restrictions between regions and agents ====
 
* An agent domain should be able to define on which regions an agent is allowed to connect
* An agent domain should be able to define which objects are allowed to be rezzed on which region (e.g. company objects only on company regions etc. This might be related to object pools as described above).
* A region might allow only certain agent domains to connect
* A region might allow anybody to connect but the rights of that agent might be limited depending from where it comes and e.g. which verification mechanism the agent provides.
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?

Latest revision as of 09:33, 24 October 2007