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: dev-unsubscr...@celix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to