pnoltes commented on issue #515: URL: https://github.com/apache/celix/issues/515#issuecomment-2016886878
Nice detailed plan for the Remote Event Admin. I have several remarks: 1) Does the Event Admin need to be aware of remote events? I was considering the possibility that a Remote Event Admin could register an EventHandler with "event.topics=*". This way, the Remote Event Admin can receive any local events and, perhaps, even filter for events marked for remote communication (something like "event.filter=(celix.event.remote.enable=true)") and send them remotely. The counterpart of the Remote Event Admin can inject messages using the local Event Admin. The downside is that, from a remote perspective, the events are always treated as a postEvent. However, considering that remote calls can lead to long blocks and possible timeouts, this approach might be preferable. 2) I appreciate the addition of qos and expiryInterval. However, I am not sure if I like the $ prefix. As far as I am aware, the OSGi standard does not use a special character prefix to indicate reserved property names but instead relies on the use of more fully qualified names (celix.event.remote.*). Although we do not have to follow the OSGi specification exactly, I prefer the OSGi approach in this case. 3) Originally, the idea with PubSub was to build remote services on top of it (the C++ Remote Service Admin even had an integration test based on this). For me, it also makes more sense to build a Remote Services Admin based on a Remote Event Admin concept (note, this would then be a Remote Service Admin that does not require remote discovery). Starting with a remote events implementation based on a broker backend seems more logical to me. A Remote Events based on RSA, or vice versa, can be addressed in a follow-up. 3) In my opinion, one of the benefits of using a message broker, as opposed to a peer-to-peer concept, is the elimination of the need for remote discovery. Instead, a broker server can be configured. This configuration can be simple, based on config properties, or more elaborate, based on configuration dependencies. Although we do not have a Config Admin, I think the concept of a configuration dependency is already usable. Therefore, perhaps it's an idea to let an MQTT Remote Service Admin depend on something like a "RemoteServiceAdminMqttConfiguration". This could be a marking interface with configuration service properties or a service with some "get" function to retrieve MQTT configuration. An instance of "RemoteServiceAdminMqttConfiguration" could be realized by reading config properties, a system-wide or local (JSON) configuration file (e.g., /etc/mosquitto.conf), or even (in the future) a dynamically discovered remote service. I expect that in most cases, a static configurat ion will be needed, but this approach keeps the option open for a more dynamic way of providing configuration. Lastly, please note that these are my thoughts. If there is an immediate need to couple a Remote Event Admin with RSA, we can, of course, more directly pursue that. -- 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
