Author: abroekhuis
Date: Thu Apr 5 06:50:22 2012
New Revision: 1309670
URL: http://svn.apache.org/viewvc?rev=1309670&view=rev
Log:
Formatting fixes
Modified:
incubator/celix/site/trunk/content/celix/community/boardreports/boardreports.mdtext
Modified:
incubator/celix/site/trunk/content/celix/community/boardreports/boardreports.mdtext
URL:
http://svn.apache.org/viewvc/incubator/celix/site/trunk/content/celix/community/boardreports/boardreports.mdtext?rev=1309670&r1=1309669&r2=1309670&view=diff
==============================================================================
---
incubator/celix/site/trunk/content/celix/community/boardreports/boardreports.mdtext
(original)
+++
incubator/celix/site/trunk/content/celix/community/boardreports/boardreports.mdtext
Thu Apr 5 06:50:22 2012
@@ -19,14 +19,16 @@ The last month we received or first larg
We have also been working on a graduation plan which is included below.
Most important issues are:
-* Improve robustness (APR, error handling etc), resulting in a first release
-* Update/Implement remote services for interoperability with Java OSGi (Apache
Felix)
-* Generate awareness and grow a community!
+
+ Improve robustness (APR, error handling etc), resulting in a first release
+ Update/Implement remote services for interoperability with Java OSGi
(Apache Felix)
+ Generate awareness and grow a community!
Graduation Plan
Celix is in incubation since November 2010. During the first one and a half
year talks where given at several conferences (EclipseCon, ApacheCon, OSGi User
Group meetings, etc).
Even though there seems to be an interest in the project, two important
questions keep coming up:
+
- What is the state of the project?
- Why no support for C++?
@@ -35,6 +37,7 @@ Trying to answer/solve these two questio
= State of the project
== Releases
+
Celix entered incubation in its early stage. There was only a proof of
concept, but no complete implementation.
This is an important reason for people to hold back and not yet use/improve
Celix, on the other hand, being hesitant also keeps Celix from growing towards
a more stable/robust solution.
To be able to use Celix the implementation has to reach, at least, a more
stable state. Over the past year lots of effort has been put into this.
@@ -42,6 +45,7 @@ Within the next half year a release has
Since a formal release takes quite some effort, it might also make sense to
provide snapshots (with documentation) to be able to reach more people.
== Committers
+
During the last months there has been an interest from Thales Netherlands to
use Celix in its middleware. In a research project they are working on an
implementation of the Device Access specification. This implementation is
donated to Celix, and the main developer has expressed the intention to
maintain the code base. Via this path a new committer has been added to Celix
[1][2].
But to be able to have a diverse community more committers are needed.
Having a release makes it easier for people to use and improve Celix. This is
one step towards more committers.
@@ -50,18 +54,21 @@ Having a release makes it easier for peo
[2]: http://markmail.org/message/q4n7562jvngd33s5
== Technical state
+
One of the important aspects of Celix is interoperability with Java OSGi
through remote services. Currently Celix has basic support for Celix to Celix
remote services, following the Remote Service Admin specification of OSGi. This
implementation has to be improved and extended to comply better to the
specification. Also a Java OSGi implementation has to be made which can
interact with the Celix implementation. Some existing opensource solutions are
available, but are either to large for our intended target platforms or rely on
to many other libraries (for example XML handling etc). To be able to have an
implementation which fits the environment ((de)serialization and protocol) it
makes sense to implement a simple solution ourselves.
Having functional remote services makes it easier to use Celix in a mixed
Java/C environment. This solution can also be positioned as an alternative to
JNI with the benefit that the Java and C components are separate processes. If
either one crashes the other part is kept running, resulting in a more robust
solution.
= C++ Support
== Technical Scope
+
Currently Celix is limited to C only. This was a deliberate choice since Celix
tries to target embedded/constrained platforms. But during talks people also
seem to be interested in C++ support. Extending the technical scope of the
project might attract more users and committers.
Over the next half year we will work out a plan how C++ support can be added
without impacting the current supported platforms. A start with the discussions
has been made on the mailinglist, see [2] for more information.
[3]: http://markmail.org/thread/a3qltqhsocmrnerd
== Cooperate with existing C++ OSGi like implementations
+
In [3] a list of similar projects is mentioned. Reaching out to these projects
and trying to find a common ground on requirements/API etc could benefit Celix
(and those projects as well).
To see if there is a common ground we need to contact those projects and plan
a meeting.
