Hi Philipp,

At the company I work for have we have been looking for an OSGi-like
C/C++ for some time and Celix is the only one that seems to be both
open-source and actively developed (for some definition of active, but
we talked to Alexander at the EclipseCon last week and he is still
involved with it :)). The plan is to use it in C++ projects.

Our main problem is the current state (read: very experimental/unstable)
of the code base. I'm not the developer carrying the project to get on
Celix so I can't say if we'll be adopting it or not (and in that case
contribute to it).

As far as I'm concerned, I think the best that Celix has to offer is
that it's not yet again a personal effort. It's something that has the
potential to grow like OSGi and once the framework is stable, people can
easily contribute compendium services & other OSGi specs (something nice
would be DS for Celix).

My argument that it's a better strategy to add to Celix' efforts rather
than start something from scratch.

Now, about using it from C++ and wanting the features that C++ has and C
hasn't, why not write a wrapper instead of starting something from
scratch? Given the fact that Celix is just mimicking OSGi's Java API (so
it's "object oriented C"), writing such a wrapper should be
straightforward (and there are very few "public classes" in Celix so
far). Of course, that means also writing a wrapper for all the services
or give up the ability to use some services from C.

I think many people would be interested in such a wrapper, including the
Celix guys. In fact, we might write one if we decide to adopt Celix.

Now, I guess you would spend most of your time fixing bugs in Celix and
not in your wrapper. Also, from your comments, it sounds like you're
targeting Windows exclusively while Celix should run on *nixes and more
as well. As far as I know, the idea is to use APR[1] to abstract from OS
specifics.


HTH,

Simon


[1] http://apr.apache.org/

Philipp Kursawe wrote on 28/03/2011 16:16:
> Hello Neil,
> 
> On Mon, Mar 28, 2011 at 3:49 PM, Neil Bartlett <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     You only mentioned it once, and you said it's not an option because
>     it's C rather that C++. I'm curious why that matters?
> 
> 
> I think to ease .net developers into the framework they would like to
> not cast from and to void*. But I don't know.
> But probably existing COM servers could work with celix with a lot of
> casting. It would just not feel natural.
> 
> 
>     When it comes to type safety, even Java OSGi is not particularly
>     typesafe as services must be casted before they can be used. At least
>     this will remain the case until 4.3 comes along.
> 
>  
> COM provides QueryInterface a java-like "instance of" functionality
> which would improve on type safety imho. At least its type safe enough
> in the current COM world.
> 
> 
>     Cheers
>     Neil
> 
>     On Mon, Mar 28, 2011 at 9:40 AM, Philipp Kursawe
>     <[email protected] <mailto:[email protected]>> wrote:
>     > Hello Felix,
>     >
>     > Uhmm yes? I mentioned it several times in my mail and also why it
>     is not an
>     > option ;) Its not C++ and its not type safe.
>     >
>     > Regards,
>     > Phil
>     >
>     > On Mon, Mar 28, 2011 at 3:13 PM, Felix Meschberger
>     <[email protected] <mailto:[email protected]>>
>     > wrote:
>     >>
>     >> Hi
>     >>
>     >> Have you heard of Apache Celix [1] ?
>     >>
>     >> Regards
>     >> Felix
>     >>
>     >> [1] http://incubator.apache.org/celix
>     >>
>     >
>     > _______________________________________________
>     > OSGi Developer Mail List
>     > [email protected] <mailto:[email protected]>
>     > https://mail.osgi.org/mailman/listinfo/osgi-dev
>     >
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to