celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pnol...@apache.org
Subject celix git commit: CELIX-402: Some small doc updates
Date Tue, 27 Jun 2017 06:42:22 GMT
Repository: celix
Updated Branches:
  refs/heads/develop f9cae1f4f -> ddc998544


CELIX-402: Some small doc updates


Project: http://git-wip-us.apache.org/repos/asf/celix/repo
Commit: http://git-wip-us.apache.org/repos/asf/celix/commit/ddc99854
Tree: http://git-wip-us.apache.org/repos/asf/celix/tree/ddc99854
Diff: http://git-wip-us.apache.org/repos/asf/celix/diff/ddc99854

Branch: refs/heads/develop
Commit: ddc998544152c8e7298a8308fca1202ad3d92815
Parents: f9cae1f
Author: Pepijn Noltes <pepijnnoltes@gmail.com>
Authored: Tue Jun 27 08:48:12 2017 +0200
Committer: Pepijn Noltes <pepijnnoltes@gmail.com>
Committed: Tue Jun 27 08:48:12 2017 +0200

----------------------------------------------------------------------
 documents/roadmap/api_v3/celix/celix.h | 42 +++++++++++++++----------
 documents/roadmap/api_v3/readme.md     | 48 ++++++++++++++++++++++-------
 2 files changed, 63 insertions(+), 27 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/celix/blob/ddc99854/documents/roadmap/api_v3/celix/celix.h
----------------------------------------------------------------------
diff --git a/documents/roadmap/api_v3/celix/celix.h b/documents/roadmap/api_v3/celix/celix.h
index 7834f19..ce77814 100644
--- a/documents/roadmap/api_v3/celix/celix.h
+++ b/documents/roadmap/api_v3/celix/celix.h
@@ -86,19 +86,20 @@ extern "C" {
 typedef struct celix_map celix_map;
 
 typedef enum celix_map_value_type {
-    CELIX_MAP_TYPE_UNKNOWN  = 0,
-    CELIX_MAP_TYPE_STRING   = 1,
-    CELIX_MAP_TYPE_PTR      = 2,
-    CELIX_MAP_TYPE_INT8     = 3,
-    CELIX_MAP_TYPE_UINT8    = 4,
-    CELIX_MAP_TYPE_INT16    = 5,
-    CELIX_MAP_TYPE_UINT16   = 6,
-    CELIX_MAP_TYPE_INT32    = 7,
-    CELIX_MAP_TYPE_UINT32   = 8,
-    CELIX_MAP_TYPE_INT64    = 9,
-    CELIX_MAP_TYPE_UINT64   = 10,
-    CELIX_MAP_TYPE_FLOAT    = 11,
-    CELIX_MAP_TYPE_DOUBLE   = 12,
+    CELIX_MAP_TYPE_UNKNOWN      = 0,
+    CELIX_MAP_TYPE_STRING       = 1,
+    CELIX_MAP_TYPE_PTR          = 2,
+    CELIX_MAP_TYPE_CONST_PTR    = 3,
+    CELIX_MAP_TYPE_INT8         = 4,
+    CELIX_MAP_TYPE_UINT8        = 5,
+    CELIX_MAP_TYPE_INT16        = 6,
+    CELIX_MAP_TYPE_UINT16       = 7,
+    CELIX_MAP_TYPE_INT32        = 8,
+    CELIX_MAP_TYPE_UINT32       = 9,
+    CELIX_MAP_TYPE_INT64        = 10,
+    CELIX_MAP_TYPE_UINT64       = 11,
+    CELIX_MAP_TYPE_FLOAT        = 12,
+    CELIX_MAP_TYPE_DOUBLE       = 13,
 } celix_map_value_type;
 
 typedef struct celix_map_entry {
@@ -129,7 +130,7 @@ celix_map* celix_map_create(void);
 /**
  * Copies (deep copy) a map
  */
-celix_map* celix_properties_copy(const celix_map* map);
+celix_map* celix_map_copy(const celix_map* map);
 
 /**
  * Destroys the map and release the memory.
@@ -1313,8 +1314,8 @@ const celix_module_registration_options CELIX_DEFAULT_MODULE_REGISTRATION_OPTION
  * If no name is provided, the module will not be registered and an error will be logged.
  *
  * When initializing the module, the framework will look for a <module_name>_resourceEntry
and
- * <module_name>_resourceEntrySize symbol. If found, the content is assumed to be embedded
zip (or tar?) file.
- * the celix_modules_files CMake command will ensure that this is linked to the module libraries.
+ * <module_name>_resourceEntrySize symbol. If found, the content is assumed to be an
embedded zip (or tar?) file.
+ * the celix_modules_files CMake command will ensure that these symbols are created and linked
to the module library.
  *
  * @param moduleName The name of the module.
  * @param moduleVersion Optional, the version of the module.
@@ -1764,9 +1765,18 @@ typedef struct celix_event {
     const celix_map* entries;
 };
 
+#define CELIX_EVENT_TOPICS      "event.topics"
+#define CELIX_EVENT_FILTER      "event.filter"
+
 /**
  * The celix_event_listener is a generic whiteboard service which can be registered
  * to handle events for specific topics.
+ *
+ * If this service is registered with the event.topics property, only those topics (comma
seperated) will trigger the
+ * onEvent callback.
+ * If this service is registered with the event.filter propertie, only event which match
the filter, using the
+ * string entries of celix_event.entries as filter target, will trigger the onEvent callback.
+ *
  */
 typedef struct celix_event_listener {
     void* handle;

http://git-wip-us.apache.org/repos/asf/celix/blob/ddc99854/documents/roadmap/api_v3/readme.md
----------------------------------------------------------------------
diff --git a/documents/roadmap/api_v3/readme.md b/documents/roadmap/api_v3/readme.md
index 387e7ed..9637b1d 100644
--- a/documents/roadmap/api_v3/readme.md
+++ b/documents/roadmap/api_v3/readme.md
@@ -24,17 +24,17 @@ handled with callbacks, to ensure correct usage of locking can be applied
more e
 ### OSGi API leaks too much details.
 The OSGi API is more than 15 years old and has grown overtime, this shows.
 There are a lot of hoops to take to use a service in a correct way.
-The proposed Apache Celix API tries to minimize the needed objects, while still provided
the same functionality.
-It was also design for a more user friendly experience, taking into account that dynamic
service can be daunting.
+The proposed Apache Celix API tries to minimize the needed objects, while still providing
the same functionality.
+It was also designed for a more user friendly experience.
 
 ### Smaller code base
 Because the OSGi leaks to much details, it is also difficult to implemented; specifically
mapped one to one from Java.
 A redesign of the API could lead to a smaller code base.
 
 ### Single framework event thread design.
-It would be beneficial to use single framework event thread, this would means that as a user
it is ensured that the
-all the callbacks are called from the same thread. Preventing issues that service can be
added/removed simultaneously
-and the locking complexity which comes with that.
+It would be beneficial to use single framework event thread,
+this would means that as a user it is ensured that all the callbacks are called from the
same thread.
+Preventing issues that service can be added/removed simultaneously and the locking complexity
which comes with that.
 With the current API this is more difficult (too many entries to shared resources).
 
 ### Multiple languages
@@ -57,11 +57,10 @@ Java has exceptions, C has not. This has lead to an initial design that
almost a
 While in principle completely correct, from a developer perspective it become cumbersome.
 Also taking in to perspective, than in many cases if an error is returned there no real way
to handle this,
 the proposed API focus more on easy of use and lenient and silently accepting invalid input
(i.e. NULL pointers
-of invalid ids).
+or invalid ids).
 
 ### Eat your own dog food
-A bit strange, but as a service oriented framework,
-the OSGi core framework specification does not provide services on itself.
+A bit strange, but as a service oriented framework the OSGi specification for the core framework
specification does not provide framework services.
 The proposed API moves some of the API for detailed info to framework services.
 
 ### Integrated event admin
@@ -77,13 +76,13 @@ TODO discuss if a more generic OSGi like prefix is desirable, e.g. nosgi_
and no
 
 ### const correctness
 The proposed API add the use of const when applicable. The usage of const adds more semantics
to the API and
-can prevent certain calls (e.g.in the callbacks) if when they should not be used.
+can prevent certain calls (e.g.in the callbacks) when they should not be used.
 
 ### Support for a more static approach
-Although Apache Celix is a framework for dynamic services, this does not mean that every
module should be runtime install/uninstall able.
+Although Apache Celix is a framework for dynamic services, this does not mean that every
module should be runtime install/uninstall-able.
 Supporting static modules and modules as "plain old libraries" can make it easier to use
and deploy application using Apache Celix.
 In this proposal, bundle are still present, but just a way to install modules. Support for
installing modules using static
- and shared libraries is also supported.
+ and shared libraries is added.
 
 ## Apache Celix V3 CMake Commands
 Apache Celix provides several CMake commands to be able to work with Apache Celix modules,
bundles and deployments.
@@ -144,6 +143,33 @@ celix_module_files(<module_target>
 )
 ```
 
+```C
+/**
+ * Registers the module for all current framework and future framework that are created.
+ * If no name is provided, the module will not be registered and an error will be logged.
+ *
+ * When initializing the module, the framework will look for a <module_name>_resourceEntry
and
+ * <module_name>_resourceEntrySize symbol. If found, the content is assumed to be an
embedded zip (or tar?) file.
+ * the celix_modules_files CMake command will ensure that these symbols are created and linked
to the module library.
+ *
+ * @param moduleName The name of the module.
+ * @param moduleVersion Optional, the version of the module.
+ * @startFp Optional, the start function which will be called if the module is going to be
added and ready to start.
+ * @startFp Optional, the stop function which will be called if the module going to be removed
and ready to start.
+ * @opts Optional, the additional options. The options will be needed anymore after the registerModule
call.
+ * @return 0 if successful
+ */
+int celix_moduleRegistration_registerModule(
+        const char* moduleName,
+        const char* moduleVersion,
+        celix_properties* manifest,
+        celix_module_registration_startModule_fp startFp,
+        celix_module_registration_stopModule_fp stopFp,
+        const celix_module_registration_options* opts);
+
+
+```
+
 ### Bundles
 Bundles are ZIP files which bundle one module.
 The CMake commands for bundle is not changed with expection of the


Mime
View raw message