Hi, > nice to hear from you.
Yes, it has been a while. I hope things are going well for you in Berlin. > As I understand, you are working on a component-framework written in C. > This is somehow different to what I was thinking of: I thought of some > C++-Bundles which can provide and use services into/from a OSGi- > Runtime. > That means that the OSGi-Runtime will manage dependencies and > lifecycle, but the C++-Bundles can participate on this through some > bridging technology ... The pure bridging is something that we have implemented in the past for R-OSGi. Since you are likely crossing process boundaries (you actually want to have separate processes to avoid the issues that JNI has), you anyway need some IPC-like mechanism (which R-OSGi can do). And, in order to communicate between modules written in Java and C/C++, you need to agree on a common type system. So if the starting point is OSGi, you probably want this type system to be the Java type system in order to have the full expressiveness of OSGi. As we pointed out in here: http://www.iks.inf.ethz.ch/publications/iot08.html , this fortunately doesn't mean that you have to implement a full type mapping to write services in languages like C/C++. Instead, it's sufficient to implement type mappings for the types involved in the conversations, namely, those used in the service interface. We managed to even implement this idea for sensor nodes with 8bit microcontroller, some few KB of RAM, running Ti! nyOS. Indeed, we didn't deal with managing the lifecycle of the services because we were running them in different processes, most of the times, even on different machines. However, this would be a first step towards what we are trying to achieve. In our model, we are trying to integrate modules from different frameworks written in/for different languages. This fits very well into the "Virtual Framework" idea that I presented at last EclipseCon. We recently received a generous grant from Microsoft (http://systems.ethz.ch/news/systems-group-awarded-grant-from-microsoft) in order to pursue this approach and (hopefully) come up with a universal component model for embedded devices. Cheers, Jan. ------------------------------------------------------------ MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH Zurich IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland http://www.systems.ethz.ch ------------------------------------------------------------ _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
