Hi, I want to propose a project for participation in Google SoC 2008 with boost. My proposal is a software component library for C++. The goal is the creation of a library that assists component based software development, bringing a well defined, existing model to C++. Is there any interest for such a library? nesC is an extension to the C language developed in UC Berkeley to support development in real-time embedded systems running tinyOS. The extensions to the C language are around the notion of components/modules and their orchestration (configuration) in order to deploy a running application. They use a meta-compiler that transforms nesC code to ANSI C, which then actually runs on the motes. Of course the nesC programming model is not tied to real-time systems and translates in large systems as well. My proposal is to provide the same model in a C++ library, without the need of a meta-compiler, but providing a DSEL. If you are unfamiliar with nesC, you can find more in http://nescc.sourceforge.net/, but below I'll give a quick overview and glossary of the terms used in the model and how they can translate in C++. - interface -- an abstract class that defines an API contains commands and events - module -- a class that is a concrete implementation of one or more interfaces, it provides and uses one or more interfaces - provide -- the relationship of a module that provides an interface is similar to the inheritance relationship, the module implements the interface's declared commands and triggers its declared events - use -- a module that uses an interface implies that it requires the existence of a module that implements that interface - command -- an exported function declared in an interface, implemented by a module - event -- a signal declared in an interface, fired by a module - configuration -- a specification of wiring (mapping) of modules to interfaces, constructing an entity that can be considered as a composite module (aka orchestration of components) - wiring -- instantiation of a module and attachment to an interface that is used by another module or configuration The benefits of component based development are obvious; clean architectural dissemination of software, self-containment of modules and orchestration of new services and applications based on already existing ones. I have adjusted the basic concepts behind nesC as presented in its web site to translate to general programming: - separation of construction and composition: programs are built out of components, which are assembled ("wired") to form whole applications. - specification of component behavior in terms of set of interfaces. Interfaces may be provided or used by components. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job. - interfaces are bidirectional; they specify a set of functions to be implemented by the interface's provider (commands) and a set of signals fired to the interface's user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens). - components can be statically linked to each other via their interfaces, furthermore components should be linked dynamically (at run-time) allowing modification of program's behavior. Below I give an example of orchestration for an IDE application where you want to setup the environment to handle C++ sources. Setup compilers, source documents, runtime env, source editor etc. configuration cpp_ide { module<ide>.interface<Compiler> -> module<gcc> module<ide>.interface<SourceFile> -> module<CppSource> module<ide>.interface<Editor> -> module<CppEditor> module<ide>.interface<Output> -> module<Console> } In the above simple example we create a configuration of the ide module, namely cpp_ide, wiring its interfaces to some implemented modules. The notation of module<> and interface<> is to help you distinguish between different entities. Alternatively, you could setup the environment for e.g. python given that you implement the proper modules, reusing code from some common modules (e.g. console and the ide infrastructure). I want to support both static configurations like this and dynamic configuration, (e.g. setup an environment depending on configuration files). Of course the true benefits of components come from the fact that they can be dynamically loaded at runtime. I intend to use the boost.extension library, which seems to have reached a stable state, for facilitating this requirement. That would require components to just depend on interfaces instead of actual implementation. In addition, I want to expand the library to interoperate with boost.reflection so that a module's interface can be wired with an arbitrary module as long as it provides the functional requirements set by the interface. In the latter case detection of incompatibilities between modules (i.e. missing functions) are postponed and handled during runtime, as they can not be resolved statically. So, please give me some feedback on whether such a library would be an interesting contribution to boost and if you want me to elaborate on my ideas for the project. Cheers, Themis