ARCS/en
Un article de Wiki-evr@.
Version du 20 juillet 2006 à 13:39 (modifier) Gi (Discuter | Contributions) (→Component Initializations) ← Différence précédente |
Version du 24 juillet 2006 à 11:27 (modifier) (défaire) Gi (Discuter | Contributions) (→Signal/slots) Différence suivante → |
||
Ligne 46 : | Ligne 46 : | ||
Our solution is based on the signal/slot communication | Our solution is based on the signal/slot communication | ||
model between components. This paradigm, mainly | model between components. This paradigm, mainly | ||
- | used in user interfaces API, | + | used in user interfaces API, reaches other scopes |
- | of | + | of programming. Some libraries are implementing |
it, for example: QT [http://www.trolltech.com ], | it, for example: QT [http://www.trolltech.com ], | ||
libsigc++ [http://libsigc.sourceforge.net] derived from | libsigc++ [http://libsigc.sourceforge.net] derived from | ||
Ligne 55 : | Ligne 55 : | ||
triggered when the signal is ”emitted”. Signals and | triggered when the signal is ”emitted”. Signals and | ||
slots can be connected and disconnected dynamically | slots can be connected and disconnected dynamically | ||
- | at runtime and are managed | + | at runtime and are managed. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
==== Component representation ==== | ==== Component representation ==== |
Version du 24 juillet 2006 à 11:27
ARCS (for Augmented Reality Component System) is a framework dedicated to the design of augmented reality applications. The core of the framework is a general purpose component system cutomized to meet the requirements of augmented reality applications (mostly real-time constraints). A set of components is developped on top of this system for augmented reality applications.
Sommaire |
Motivations
During the last years, AR (Augmented Reality) community has proven the need of an infrastructure. Almost 30 different projects of framework have been developed for AR [Endres05].
Amongst these projects, the most remarkable ones are :
- Studierstube, one of the oldest project relying on a ditributed scenegraph,
- Tinmith, which is oriented for developpers,
- Dwarf, developped for distributed augmented reality services,
- AMIRE, which is the closest architecture to ARCS.
Our choice is to develop or rely on a component system that meets several requirements such as portability, a variable granularity, some scalability, and a high level of abstraction for end-users. As we will see, we will introduce component life-cycle management mechanisms in ours application developed with our framework. We will also combined it with with a system allowing on-line reconfiguration of data-flow.
The ARCS Core
Components
According to Szyperski’s definition [Szyperski02], “A component is a coherent package of software that can be independently developed and delivered as a unit, and that offers interfaces by which it can be connected, unchanged, with other components to compose a larger system”.
It means that, the way components will communicate with each other should be described, how they’re implemented, how they’re initialized and how we can use them to build applications.
Signal/slots
Our solution is based on the signal/slot communication model between components. This paradigm, mainly used in user interfaces API, reaches other scopes of programming. Some libraries are implementing it, for example: QT [1], libsigc++ [2] derived from GTK+, sigslot [3] and boost [4]. Signals represent callbacks with multiple targets. Signals are connected to some set of slots, which are callback receivers. They are triggered when the signal is ”emitted”. Signals and slots can be connected and disconnected dynamically at runtime and are managed.
Component representation
A component in ARCS is an entity or object able to export by itself its interface which is made of signals and slots. As we will see, we will often use both the terms of components and objects to refer to the same thing, since the components we will develop are objects.
Component libraries
Components are compiled pieces of code stored in dynamic libraries with three specific entry points:
- one for describing objects stored in the library,
- one for instantiating an object contained in the library,
- one for destroying an object instantiated from this library.
Once components are stored in dynamic libraries, we can load and use them on demand. Therefore, a component may require some configuration so we need a system to set component properties.
Component Initializations
Components initializations are performed through slots. However, these slots must meet a few requirements. They must have only one parameter and this parameter belongs to a list of simple types such as strings, numerical values and other components.
Further, we will establish a distinction between two kinds of initializations depending on when they’re triggered. Indeed, a slot call can also trigger a signal that belongs to the same component; this last one may call another slot if a signal/slot connection is established between them. So, we have Pre-connection initializations that are performed before the component is connected with others and we have a second category we call post-connection initialization that are triggered after the component is connected to other ones. This second one allows propagating initializations through connections.
Since a component can be connected to other components,
we will see the different solutions we have to
connect components.
Compositions of components
The sheet, an explicit composition
Initialisations of components
Other composition mechanism
Extending the sheet capabilities
Publications
J.Y. Didier, S. Otmane, M. Mallem - A Component Model for Augmented/Mixed Reality Applications with Reconfigurable Data-flow