Talk:Definitions - Revision history

Jhurliman at 21:42, 15 October 2009

2009-10-15T21:42:34Z

Diva at 21:19, 15 October 2009

2009-10-15T21:19:57Z

Diva at 21:04, 15 October 2009

2009-10-15T21:04:28Z

Diva at 21:00, 15 October 2009

2009-10-15T21:00:10Z

Diva at 20:24, 15 October 2009

2009-10-15T20:24:06Z

Diva at 20:20, 15 October 2009

2009-10-15T20:20:15Z

Jhurliman: New page: We need an overhaul of term definitions in OpenSim before we can clean up the ScenePresence vs. ClientManager mess. Here's a starting point, feel free to revise/append/discuss: ===Entity=...

2009-10-15T18:03:28Z

New page: We need an overhaul of term definitions in OpenSim before we can clean up the ScenePresence vs. ClientManager mess. Here's a starting point, feel free to revise/append/discuss: ===Entity=...

New page

We need an overhaul of term definitions in OpenSim before we can clean up the ScenePresence vs. ClientManager mess. Here's a starting point, feel free to revise/append/discuss:

===Entity===
An entity in OpenSim is "something that exists in the 3D simulation". It has a position in the world, a rotation, velocity, etc. It is responsible for providing a physical proxy that can be handed off to a physics engine. It might break every rule and be invisible, static, and have no physical proxy but it must still implement all of these concepts.

===Prim===
A prim is one type of entity that is very common in OpenSim. It has roots in the Second Life(tm) world, and is a procedurally generated basic shape that has an efficient network representation. It implements the basic concepts required to be an entity, plus many additional concepts that are specific to the LLUDP protocol. It also implements some extra generic concepts in OpenSim, such as acting as a script container.

===Mesh===
Although mesh support was originally introduced as a proof of concept in OpenSim by the realXtend team, there are many different types of mesh representations and file formats. This blanket term refers to any type of entity that stores geometry data instead of procedural instructions to generate geometry. Depending on the implementation, a mesh may or may not implement additional interfaces such as the scripting container interface or LLUDP concepts.

===Avatar===
An avatar is a specially identified entity that acts just like any other entity (takes up space in 3D, provides a physical proxy, etc). In addition to their 3D presence, avatars have many concepts attached to them such as owning inventory, having groups and friends, and belonging to access control lists that grant or deny them permissions throughout the world.

===Client===
A client is something that connects to the simulation. This may be an end user that has a Second Life(tm) viewer and wants to connect as an avatar, a search engine that wants to connect to the simulator and scrape information, a proxy that is managing hundreds of avatar connections, an external engine that is sending and receiving data to control the simulation, or anything else that needs to establish a connection to the simulator. Clients are distinguished by the protocol they use to communicate, such as a LindenUDP client vs. an MXP client. OpenSim is moving away from the concept of monolithic client interfaces to many smaller client interfaces, so one implementation may implement everything used in the LLUDP protocol while another may only implement chat and IM. These are event driven interfaces. For example, if an entity moves in the scene, any clients that are listening for entity movements will be notified and are responsible for converting the movement event into a network event.

===Endpoint===
Although clients can have very different implementations, one requirement is that each client can be identified by a single remote endpoint (IPEndPoint). This allows indexing and generic operations across clients regardless of their implementation.

===Viewer===
The viewer concept plays a very minor role in the OpenSim architecture. Some client implementations may use the concept of viewer software that is responsible for the client-side of the networking, but viewers do not exist outside of individual client implementations. For example, the LindenUDP implementation may choose to define a viewer concept and the MXP implementation may also choose to define its own viewer concept, but a remote scripting engine client implementation would have no such concept.

===Presence===
HELP: What is a presence? I can't think of a good definition. Entities are 3D simulated concepts, avatars have all of the avatar-specific concepts, clients process network events, presence seems to be a hack to merge all of these together. Should we try to remove the concept of a presence altogether? This needs more thought.

@@ Line 56: / Line 56: @@
 ===Relations between these concepts===
-* The "normal" chain: a ''user'' uses a ''client'' program to connect to an OpenSim server; inside OpenSim, this connection is represented by an ''agent'' which is associated with a ''scene presence/avatar''; the ''agent'' acts on behalf of the ''user'' in order for the OpenSim server to access the user's services.
+* The "normal" chain: a ''user'' uses the LL ''client'' program to connect to an OpenSim server; inside OpenSim, this connection is represented by an ''agent'' which is associated with a ''scene presence/avatar''; the ''agent'' acts on behalf of the ''user'' in order for the OpenSim server to access the user's services.
 * An agent may or may not be associated with a scene presence. Some agents may simply not have scene presences at all (e.g. a search engine http bot, or even sophisticated agents that send back graphical information but are "invisible").
 * A Scene Presence may or may not be associated with an agent. Some scene presences may simply not have agents behind them at all (e.g. server-side characters).

@@ Line 56: / Line 56: @@
 ===Relations between these concepts===
-* An agent may or may not be associated with a scene presence. Some agents may simply not have scene presences at all.
+* The "normal" chain: a ''user'' uses a ''client'' program to connect to an OpenSim server; inside OpenSim, this connection is represented by an ''agent'' which is associated with a ''scene presence/avatar''; the ''agent'' acts on behalf of the ''user'' in order for the OpenSim server to access the user's services.
 * A Scene Presence may or may not be associated with an agent. Some scene presences may simply not have agents behind them at all (e.g. server-side characters).

@@ Line 50: / Line 50: @@
 ===Client===
 Any external program that connects to OpenSim servers via a network. It's not part of OpenSim.
 ===Relations between these concepts===
@@ Line 55: / Line 58: @@
 * An agent may or may not be associated with a scene presence. Some agents may simply not have scene presences at all.
 * A Scene Presence may or may not be associated with an agent. Some scene presences may simply not have agents behind them at all (e.g. server-side characters).

← Older revision		Revision as of 20:24, 15 October 2009
Line 54:		Line 54:

	* An agent may or may not be associated with a scene presence. Some agents may simply not have scene presences at all.		* An agent may or may not be associated with a scene presence. Some agents may simply not have scene presences at all.
−	* A Scene Presence may or may not be associated with ~~a client~~. Some scene presences may simply not have ~~clients~~ behind them at all (e.g. server-side characters).	+	* A Scene Presence may or may not be associated with an agent. Some scene presences may simply not have agents behind them at all (e.g. server-side characters).

@@ Line 1: / Line 1: @@
 We need an overhaul of term definitions in OpenSim before we can clean up the ScenePresence vs. ClientManager mess. Here's a starting point, feel free to revise/append/discuss:
 ===Entity===
@@ Line 8: / Line 10: @@
 ===Mesh===
 Although mesh support was originally introduced as a proof of concept in OpenSim by the realXtend team, there are many different types of mesh representations and file formats. This blanket term refers to any type of entity that stores geometry data instead of procedural instructions to generate geometry. Depending on the implementation, a mesh may or may not implement additional interfaces such as the scripting container interface or LLUDP concepts.

@@ Line 12: / Line 12: @@
 ===Avatar===
 An avatar is a specially identified entity that acts just like any other entity (takes up space in 3D, provides a physical proxy, etc). In addition to their 3D presence, avatars have many concepts attached to them such as owning inventory, having groups and friends, and belonging to access control lists that grant or deny them permissions throughout the world.
 ===Client===
-A client is something that connects to the simulation. This may be an end user that has a Second Life(tm) viewer and wants to connect as an avatar, a search engine that wants to connect to the simulator and scrape information, a proxy that is managing hundreds of avatar connections, an external engine that is sending and receiving data to control the simulation, or anything else that needs to establish a connection to the simulator. Clients are distinguished by the protocol they use to communicate, such as a LindenUDP client vs. an MXP client. OpenSim is moving away from the concept of monolithic client interfaces to many smaller client interfaces, so one implementation may implement everything used in the LLUDP protocol while another may only implement chat and IM. These are event driven interfaces. For example, if an entity moves in the scene, any clients that are listening for entity movements will be notified and are responsible for converting the movement event into a network event.
+A client is something that connects to the simulation via a network. This may be an end user that has a Second Life(tm) viewer and wants to connect as an avatar, a search engine that wants to connect to the simulator and scrape information, a proxy that is managing hundreds of avatar connections, an external engine that is sending and receiving data to control the simulation, or anything else that needs to establish a connection to the simulator. Clients are distinguished by the protocol they use to communicate, such as a LindenUDP client vs. an MXP client. OpenSim is moving away from the concept of monolithic client interfaces to many smaller client interfaces, so one implementation may implement everything used in the LLUDP protocol while another may only implement chat and IM. These are event driven interfaces. For example, if an entity moves in the scene, any clients that are listening for entity movements will be notified and are responsible for converting the movement event into a network event.
 ===Endpoint===
@@ Line 24: / Line 28: @@
 ===Presence===
 HELP: What is a presence? I can't think of a good definition. Entities are 3D simulated concepts, avatars have all of the avatar-specific concepts, clients process network events, presence seems to be a hack to merge all of these together. Should we try to remove the concept of a presence altogether? This needs more thought.