From: Eric B. <eb...@us...> - 2000-08-26 01:18:55
|
Also available at: http://arlut.utexas.edu/~bresie/3d/chat-traffic-08-24-2000.htm. Here is a summary of topic discussed on the irc.openprojects.net server on the #3Dsia channel on 08-24-2000 during the time I was logged on. In future this may be taken directly from the log file. Some of this is based on lose translations so forgive me for inaccuracies. Please correct me where appropriate. Some editorial comments are included through the summary. Some descriptions of the Client Architecture/Design were given. This included a description of how the Matrix Proxy interacts with other components. It communicates with the I/O Component and with the Render Component (the Visual Component). The I/O Component in turn is made up of an Input Component and an Output Component. The I/O Component is somewhat grouped together, but is more of an abstract component. The Visual Component is roughly at the same level as the Input/Output Component in regards to Matrix-Proxy interaction. The Plugins will communicate with the Input and Output Component. For further representation of the interaction, see http://threedsia.sourceforge.net/client.eps It shows the client-stubs design and interaction. Some diagramming tools were discussed which include Dia and Xfig. Future attempts for interaction and design diagrams will be attempted in Dia, which is capable of doing UML diagramming (see http://www.lysator.liu.se/~alla/dia/ for more information about Dia, and http://www.xfig.org/ for more information about XFig) Some concerns about LOD (Level Of Detail (?)) was questioned. Agent Communication, Transport, and Client Stub were mentioned. Each Visual Component will have an Agent to interact with the Matrix Proxy, which has a Stub on the server. An additional output device (such as a force feedback glove) was mentioned and how they interact with the Visual output. Usage of visual and sound output may affect the force feedback glove. This type of device would be an output device, although it could also be an input device if used for position and hand movement. This may indicate that it has an input component and an output component (plugin perhaps). Distingsion between an output device and a rendering device were discussed. This discussion of the force feedback glove was shelved for future discussion. Usage of the force feedback may be usable for blind. There may be some confusion on the following due to translation problems. There was concern about the interaction and number of processes that would occur if each visual item got an agent, which would in turn require the same number of stubs on the server. But the client-stubs and the agent would be together on the server. The Agent is part of the Matrix-Proxy and rules the connection to the Matrix. The Agent is an ODB-agent, which prepares the output for the output plugin out of the ODB. It processes MetaEvents and inserts data into the ODB, and retrieves data from the ODB. The client-stub is on the server with the 3Dsia Daemon, with the agents. When there are non-visual depended modules, then no agents/agent-stub exist, but the Server Daemon still exists. When a visual dependant occurs, an agent is started within the Matrix-Proxy. The Server Daemon authenticates the agent. There exist an agent for the proxy and an agent for the client-stub. The agent is responsible for the authentication with the Server Daemon. Communication occurs between agents, not between matrix to matrix. The data to be retrieved is handled by the agent, allowing for a subview of the whole view. Optimization could occur on the agent to identify the data to retrieve. There will be an agent for each Visual Layer. The Matrix Proxy maintains the global view on a given server and the agents act as filters of that global view. The Transport Daemon ensures the transport. Security occurs not in the Transportation Daemon but through an agent-stub/client-stub. The agent authenticates itself against his stub. The stub is the representation of the trusted client on the server. Each Module has a queue for data (messages, events, data,etc). They exist prior to the Transportation Component. Input and Output Modules do not have a queue per say since they have to be handled immediately. Anything not handled is blocked. When an agent is initialized, it is authenticate via the stub on the server and gain credentials, then the agent is allowed to interact with the matrix. Exact security measures are either based on existing unix permissions (owner, group, other) or a seperate security source such as the PAM authentication API. Optimization of events may occur in other modules (may also include priority as well), which may allow a queue for optimization. Events/Messages/Data will be queued on the transport side, not on the Input/Output Modules. A Mouse driver is an example of this. A Mouse Driver does not queue the mouse events. The Mouse Driver accumulates the position data. If it is not queried, for a while, the position make a jump. However multiple mouse events may occur, but these may be seen as a combined single event. In other words, the kinds of events may avoid some of these needs for multiple events at the same time. Constantly checking the queue or device was viewed as polling use, which may not be efficient though. Keeping the Input/Output handling simple was re-emphasized. Waiting for sequential events for the visualization client was not acceptable. A suggestion of having an input queue, which received and combined, if necessary, was suggested. The matrix interprets input events and generates output events as an echo to an input event or an message from an other object. The intent is to prevent the seeing 100 frames of moving after you have moved by 100 mouse steps if your connection is slow. The V-modules are asking the matrix independently of the I/O-system, so there is no need to spool any kind of event over the V-module. I/O/V are independent! Distinction between low-level and high level events was mentioned. An example of a mouse movement a low-level and a middle/high level abstract event ("Move Avatar from point A to Point B") were given. The matrix will receive, for example, positioning events, not mouse-moves. The data from the input/output layer to the matrix proxies are more avatar/object updates. The middle/upper level abstract events are similar to the "object update" events in the Application API. Focusing on the kernel system or lower level design was required. It has been suggested, avoiding using the term kernel, since this may confuse some with that of the OS kernel. There are many similarities to the Application API and the Kernel/Low-Level API. The Application API may effect the Low-Level API. An example of these similarities is the message/event handling. The content of the messages may be handled differently though at different levels. The desire is to keep the Low-Level (Kernel) Modules small, generic and fast. This is the reason that it is preferred to avoid the Application level API. The exposed API of the 3Dsia kernel will contain more similarities to the Application level API. But overloading of some of the basic functions was also suggested. The Module interface inside the kernel will be based on the system requirements. Comparing the Kernel Level (low-level) calls to system calls vs upper level calls of the same name. An example of this is the similarity of having a read at OS kernel level and userspace application level. There were disagreements about the requirements of the application programmer effecting the kernel level interfaces. The desire to keep it simple was emphasized. An example of the user-api effecting the kernel-api was given in the form of real time position update would require the kernel to be able to support such request from the user-level program. Creation of a kernel-lib and a user-lib was suggestion containing the corresponding interfaces. Another example of user-api effecting kernel-api was given in the form of the programmer wanting to use an advance math processing on some chip a, and then try the same thing on chip b, which does not support it, then you have to implement the feature not supported on chip b, which eventually, I guess will get moved into a kernel level if needed. Initial implementation was desired, with enhancements and optimizations coming later Identifying some of the Transport Daemon interfaces was discussed. The transportation will be connection oriented (not connection-less). The interface will include things such as: open, close, read (receive), and write (send). An existing connection to the server is assumed. The following existing ones were suggested: register, deregister, status The objects transported would be independent of the type of objects. The actual transport will be in whatever transport protocol desired. The open interface will handle some of the underlying server registration info (which is store in the Matrix (ODB). Authorize for initializing a connection is necessary. Open could also be thought of as "login". When the connection is opened, credentials (or a ticket) are given which allows continual usage of the connection. The Matrix Proxy interfaces were mentioned. A suggested interface included: init_matrix (odb), register_server, register_client, register_client_app, add, delete, update, read(recive), and write(send). But some of these were seen as inappropriate at this level. Preferred interface between clients and servers were open, read, write, close. The client machine will have a more dedicated interface between the V-modules and the proxy-matrix-daemon. These interface contains functions like register_*, add_*, delete_*. Register_server will be generateed automatically if an V-client need to connect to a server and he calls the proxy-matrix for it The detailed operations are coordinated by the agent of the V-module. Simiarities between the two were seen and suggested a naming scheme of mp_read, mp_write,etc for the Matrix interface and trans_read, trans_write, etc for the Transport Interfaces. The data being transferred was seen as a logical interface, while the data packets themselves are physical interface. The packet is physical, the information and the way of it, is logical. Only 4 functions (physically) are need (logically) because we will transport packets, therein with information. The physical functions will build the transport-interface for all the different transport modules so this functions will be the same in each transport module(/layer) An observation of the 3Dsia design mapping to the OSI model was made. With the 3Dsia being responsible for the Session Layer and above, while the Transport and lower is handled by existing transport protocols, which can use any available protocols that is used. The reason being that each layer of the OSI model talks to other apps at the same level, but in actuality, it communicates with the layer above and below (if it exists). "OSI (Open Systems Interconnection) is a standard description or "reference model" for how messages should be transmitted between any two points in a telecommunication network. Its purpose is to guide product implementors so that their products will consistently work with other products. " This comes from the following reference: http://www.whatis.com/WhatIs_Search_Results_Exact/1,282033,,00.html?query=OS Iwww.whatis.com/WhatIs_Search_Results_Exact/1,282033,,00.html?query=OSI The http://www.whatis.com site has good overviews and links to additional information. A suggested reference of an existing client/server design was given. This was the X-Protocol Design Overview, available at: http://www.X.Org/about_x.htm |