pnoltes commented on issue #515:
URL: https://github.com/apache/celix/issues/515#issuecomment-1501665110
> @pnoltes Do you have a development plan for EventAdmin？ If no, I'd like do
it.
I had no concrete plans for this yet, so please feel free to pick this up
:smile:.
> And I have a question about netstring serialization. If we use netstring
to serialize celix_properties, it may lose type information about the property
value. I think TLV(type-length-value) serialization may be better.
Yes you are correct, if #470 is merged, properties will support property
value type. So I agree an other option would be better.
Note that there is a old and experimental implementation of the event admin
at:
https://github.com/apache/celix/tree/rel/celix-2.3.0/misc/experimental/bundles/event_admin/event_admin
But I think this can be ignored and maybe only used for inspiration.
What I remember from the experimental event admin impl is that we struggled
with when a Event object could be destroyed and who should destroy it.
An option to solve this (IMO) more elegant is to drop the Event type and
just reuse a string and celix properties. So a event admin interface like:
```c
typedef struct celix_event_admin {
void* handle;
/**
* @brief async post event call. Event admin will take ownership of the
eventProperties and destroy it when no longer needed (events are handled)
*/
celix_status_t postEvent(void* handle, const char* eventTopic,
celix_properties_t* eventProperties);
/**
* @brief sync send event call. Caller keeps ownership of eventProperties
and eventProperties can safely be destroyed after the call returns
*/
celix_status_t sendEvent(void* handle, const char* eventTopic, const
celix_properties_t* eventProperties);
} celix_event_admin_t;
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
