celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Native OSGi
Date Wed, 30 May 2012 07:22:01 GMT
Hi all,

As mentioned on the list, last week we had a meeting to discuss the future
of Celix and the possibilities for C++ bindings.

This meeting was attended by:
* Sascha Zelzer (CTK Plugin Framework)
* Marcel Offermans (Celix Mentor/Champion)
* Pepijn Noltes (Celix Committer)
* Myself (Alexander Broekhuis) (Celix Committer)

Even though Sascha was the only "external" person, he received some input
from two other OSGi like frameworks (nOSGi and SOF).

A summary of this meeting, as well as a rationale for native OSGi
solutions, can be found on [1]. Most notably is that we see a shared
interest and a need for a standardized specification (API, Bundle format,
etc) to be able to share and reuse bundles between those projects.

To this end we have set up a repository on GitHub [2] with the goal to have
one place for shared resources. For example header files, specifications
etc. We like to call this the Native OSGi specification.

Since this effort will try to provide a solution for C as well as C++, the
GitHub repository will also be used to share C/C++ bindings. This makes it
possible to use/implement bundles in a natural way for both languages.

== So what does this mean for Celix?

>From this point on we like to see Celix as a reference implementation for
the specification. So there will probably some changes to the codebase. The
impact of these changes still have to be researched and discussed.

For a start, the information on the GitHub repository has to grow to
something which can be used. To reach this we need a medium for some
discussions, and we want to use the Celix mailing list for this.

While this is a good start, this will still take a lot of work. I am
looking forward to these discussions, and think this is the right direction
to go!

Feel free to participate in these discussions and provide input where you
all see fit!

[2]: https://github.com/abroekhuis/NativeOSGi

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message