You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@celix.apache.org by Alexander Broekhuis <a....@gmail.com> on 2013/05/22 09:17:33 UTC
[Native-OSGi] Progress update
Hi all,
Quite some time ago there was already something mentioned about Native-OSGi
[1]. To recap: Native-OSGi is an effort to create a common specification
for OSGi in C and C++. This effort was started by the CTK Plugin Framework,
nOSGi and Apache Celix and although it has been rather quiet, there has
been a lot of progress.
This progress is not as much on the technical front, but more on the
procedural front. During our initial talks we were asked if it would be
worthwhile to write the Native-OSGi specification as an OSGi Alliance RFC.
For us this meant a big boost in confidence wrt the specification. So of
course we said yes to this!
So in the past period we have been working on a RFP which is the first step
towards writing the RFC for Native-OSGi. And now about a week ago this RFP
has been published for the general public to read, discuss and comment on
[2].
For this work we would like to use Celix (and the Celix project) as home
for, and as, the reference implementation. While Celix is writtin in C,
Native-OSGi also specifies a C++ implementation, as such we do like to
extend Celix to also support C++, but also like to start some discussion
wrt a implementation in C++.
So I would like to invite everyone to read and comment to the RFP on [2],
but also would like to hear your comments regarding Celix and Native-OSGi
and as Reference implementation as a reply to this mail.
Thanks!
[1]: http://incubator.markmail.org/thread/7rqtyp2so2duapfy
[2]: https://www.osgi.org/bugzilla/show_bug.cgi?id=165
--
Kind regards,
Alexander Broekhuis
Re: [Native-OSGi] Progress update
Posted by Alexander Broekhuis <a....@gmail.com>.
Hi,
2013/6/12 Sascha Zelzer <s....@dkfz-heidelberg.de>
> Hi,
>
> I just wanted to confirm that I think moving forward with the Celix
> project and extending it to support C++ is an important step.
>
Great to hear this!
>
> To get started, we should probably discuss the directory layout of the
> Celix code repository. With respect to a (hypothetical) C/C++ OSGi spec, we
> could first try make the distinction between interfaces and implementation
> apparent at the directory level. A first (incomplete) shot of mine trying
> to cope with these new requirements looks like this:
>
I'd like to take some smaller steps in this, and start with a "new"
directory for the Native-OSGi compliant implementation. Some reasons are:
* Celix relies on APR all over the place, also on the API level. This was
an explicit choice when we made it. Moving to Native-OSGi breaks the
current Celix API.
* We have a (small) userbase using Celix, I would like to keep the current
codebase supported for them, see above point.
* Creating a new subproject gives us the opportunity to work on it and
breaking stuff, without to much impact on the current Celix source.
>
> cmake
> ...
> framework/ <-- current Celix C implementation
> framework++/ <-- new Celix C++ stuff
> |---- wrapped/ <-- C++ implementation using the existing C impl.
> L---- native/ <-- independent C++ implementation (for experimentation)
> ...
> osgi/
> |---- framework/
> | |---- include/
> | | L---- osgi/
> | | |---- BundleContext.hxx <-- C++ interface
> | | L---- bundle_context.h <-- C interface
> | L---- src/
> |---- cm/
> | |---- include/
> | | L---- osgi/
> . | L---- cm/
> . | |---- ConfigurationAdmin.hxx
> . | L---- configuration_admin.h
> - L---- src/
>
This layout looks good, but I'd like to see is to make "framework" the new
Celix C implementation which is Native-OSGi compliant.
>
>
> I tried to just add stuff on top of the existing repository to keep the
> impact low. With the second-level dirs, we could also add more
> sub-directories by e.g. having "c" and "cpp" folders below osgi/framework/
> , but I thought trying to keep the hierarchy from getting too deep is
> better. We would still have to figure out how C and C++ implementations of
> service specifications could be marked as such and distinguished from each
> other (as long as these implementations are not contained in their own
> repository).
>
I'd like to follow the Celix directory layout a bit more and also use the
public and private directories. This gives a good sense as to what should
be exported and what not (wrt osgi metadata, but also wrt including and
building). Also, I do think have a c and cpp folder makes sense. That way
it is immediately clear in what language(s) a module is implemented.
Also, in your example you have eg "osgi/cm/include/osgi/cm", is the second
"osgi/cm" needed? For C it is an unneeded duplication, and it doesn't add
any extra information. It is already placed in the "osgi/cm" directory, so
why use it again?
Has it to do with C++ namespaces? If so, I'd like to split the h and hxx
files into own directories, this keeps the namespace specific for C++ and
doesn't make C use paths to include files.
I prefer the language directory on a higher level, if a certain module
doesn't have a c (or cpp) implementation or doesn't have any private files,
the directory isn't needed. Adding it later on doesn't have an impact on
the already existing directories etc.
cm/
c/
private/
include/
src
public/
include/
configuration_admin.h
src
cpp/
private/
include/
src
public/
include/
osgi/cm/ConfigurationAdmin.hxx
src
>
> I would be more than happy to contribute the work done in the Native OSGi
> directory so far (especially the C++ interfaces [1]).
>
If the others agree, I'd like to use that contribution as a means to make
you committer ;). So yeah, I'd like to that code moved to Celix.
--
Met vriendelijke groet,
Alexander Broekhuis
Re: [Native-OSGi] Progress update
Posted by Sascha Zelzer <s....@dkfz-heidelberg.de>.
Hi,
I just wanted to confirm that I think moving forward with the Celix
project and extending it to support C++ is an important step.
To get started, we should probably discuss the directory layout of the
Celix code repository. With respect to a (hypothetical) C/C++ OSGi spec,
we could first try make the distinction between interfaces and
implementation apparent at the directory level. A first (incomplete)
shot of mine trying to cope with these new requirements looks like this:
cmake
...
framework/ <-- current Celix C implementation
framework++/ <-- new Celix C++ stuff
|---- wrapped/ <-- C++ implementation using the existing C impl.
L---- native/ <-- independent C++ implementation (for experimentation)
...
osgi/
|---- framework/
| |---- include/
| | L---- osgi/
| | |---- BundleContext.hxx <-- C++ interface
| | L---- bundle_context.h <-- C interface
| L---- src/
|---- cm/
| |---- include/
| | L---- osgi/
. | L---- cm/
. | |---- ConfigurationAdmin.hxx
. | L---- configuration_admin.h
- L---- src/
I tried to just add stuff on top of the existing repository to keep the
impact low. With the second-level dirs, we could also add more
sub-directories by e.g. having "c" and "cpp" folders below
osgi/framework/ , but I thought trying to keep the hierarchy from
getting too deep is better. We would still have to figure out how C and
C++ implementations of service specifications could be marked as such
and distinguished from each other (as long as these implementations are
not contained in their own repository).
I would be more than happy to contribute the work done in the Native
OSGi directory so far (especially the C++ interfaces [1]).
Looking forward to the discussions!
Thanks,
Sascha
[1]
https://github.com/abroekhuis/NativeOSGi/tree/master/src/api/cpp/include/osgi
On 05/22/2013 09:17 AM, Alexander Broekhuis wrote:
> Hi all,
>
> Quite some time ago there was already something mentioned about Native-OSGi
> [1]. To recap: Native-OSGi is an effort to create a common specification
> for OSGi in C and C++. This effort was started by the CTK Plugin Framework,
> nOSGi and Apache Celix and although it has been rather quiet, there has
> been a lot of progress.
>
> This progress is not as much on the technical front, but more on the
> procedural front. During our initial talks we were asked if it would be
> worthwhile to write the Native-OSGi specification as an OSGi Alliance RFC.
> For us this meant a big boost in confidence wrt the specification. So of
> course we said yes to this!
>
> So in the past period we have been working on a RFP which is the first step
> towards writing the RFC for Native-OSGi. And now about a week ago this RFP
> has been published for the general public to read, discuss and comment on
> [2].
>
> For this work we would like to use Celix (and the Celix project) as home
> for, and as, the reference implementation. While Celix is writtin in C,
> Native-OSGi also specifies a C++ implementation, as such we do like to
> extend Celix to also support C++, but also like to start some discussion
> wrt a implementation in C++.
>
> So I would like to invite everyone to read and comment to the RFP on [2],
> but also would like to hear your comments regarding Celix and Native-OSGi
> and as Reference implementation as a reply to this mail.
>
> Thanks!
>
> [1]: http://incubator.markmail.org/thread/7rqtyp2so2duapfy
> [2]: https://www.osgi.org/bugzilla/show_bug.cgi?id=165
>