Hi,
I thought this might be of interest to you guys:
When I implemented the event admin spec in C++ for the CTK Plugin
Framework, I also literally took the Felix Java implementation and
translated it to C++ (including the fancy stuff like sending
asynchronous events in parallel and blacklisting handlers given a
certain timeout). After the implementation, I did a performance test of
the event admin (from Felix, Equinox, Knopflerfish, and CTK) and found
out that Felix performed the worst. This might be due to the more
complex implementation (related to blacklisting etc.) but I didn't
review the other Java implementations enough.
I attached screenshots of the diagrams showing some numbers (The
Knopflerfish event admin was by far the best performing) . The used
versions are:
Knopflerfish 3.4.0 with the packaged Event Admin bundle (version 3.0.7)
Eclipse Equinox as provided in Eclipse 3.7 together with the Eclipse
Event Admin bundle (version 1.2.100)
Felix Framework (version 4.0.3) with the Felix Event Admin bundle
(version 1.3.2).
Best,
Sascha
On 08/12/2013 11:25 AM, Alexander Broekhuis wrote:
Hi Erik,
Great work! If I have some time left I will take a more detailed look into
everything you did/are doing.
For now some remarks regarding the headers, first is the formatting. On [1]
and [2] some more details are available. It doesn't use the _pt convention
yet, but the other parts should be clear.
Especially function naming is important. Simply have a function equals in
event.h is a great recipe for failure ;). If any other included part also
has an equals function the build will fail. So it is better to use
"event_equals". This might also applies to the constants..
Second remark/improvement: You now have included the service headers (ie
the structs with function pointers), for implementation details I always
try to make a private header as well, eg "event_admin_private.h" in which
all functions are declared, instead of only functions pointers. For a user
not relevant, but for a maintainer/implementor they are.
Also for implementation details it might be worthwhile to check out the
Felix implementation. For several parts of Celix I took the Felix
implementation as a reference. They already have a working and proven
solution for a long time, so why reinvent stuff when we can learn and take
from a good reference.
[1]: http://incubator.apache.org/celix/documentation/design.html
[2] http://incubator.apache.org/celix/documentation/mapping.html
2013/8/12 Erik Jansman <[email protected]>
Hello,
I have attached the header files created for the event admin. I have left
out the eventProperties and TopicPermissions at this point. The
topicPermission is a security aspect which I wanted to leave out of the
google summer of code project in order to be able to have more change to
get the project done in time. I have left the eventProperties out of the
implementation because I'm unsure of how it is supposed to work and if it
is needed.
Event_admin, event_handler and event_constants are all as far as I can
tell confirming to the specification. In event.h there is a method equals
which according to the spec will do: "Compares this Event object to another
object.
An event is considered to be equal to another event if the topic is equal
and the properties are equal.
The properties are compared using the java.util.Map.equals() rules which
includes identity compar-
ison for array values." I was thinking of first implementing by comparing
two pointers and not check on all properties.
What does everyone think of the header files?
