xuzhenbao commented on issue #515: URL: https://github.com/apache/celix/issues/515#issuecomment-2019332332
> 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. According to the EventAdmin specification: > The Event Admin service must be registered as a service with the object class org.osgi.service.event.EventAdmin. Multiple Event Admin services can be registered. Publishers should publish their event on the Event Admin service with the highest value for the SERVICE_RANKING service property. This is the service selected by the getServiceReference method. Maybe we can implement an EventAdminWrapper, which implements the Event Admin Service, and its service ranking is the highest. In this way, EventAdminWrapper can forward events to remote (use EventRemoteProvider) or to local (use EventAdmin). And EventAdmin can be unaware of remote events. In addition, should we consider multiple EventRemoteProviders existing? If yes, EventAdminWrapper can also be used to implement a strategy to select the perfect EventRemoteProvider to forward remote events. For the MQTT broker address information, it maybe requires dynamic discovery in my work. Maybe we can implement dynamic discovery in the following ways: 1. Use the previously mentioned remote service registration mechanism. But it has the following two disadvantages: - RSA is required - In the case of multiple network interfaces, it can't choose which network interface the broker address information is exposed on. 2. Making discovery independent of RSA and REA. The problem with this approach is that if discovery is implemented based on bonjour, then the MQTT service should have a specific service name "_mqtt._tcp" (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=MQTT), which conflicts with the service name we have defined ("_celix-rpc._udp"). I haven't a solution to this problem currently. Maybe we need to give up using the service name "_mqtt._tcp", otherwise discovery_zeroconf may expose the details of bonjour. 3. Using the bonjour client to implement dynamic discovery of the MQTT broker service address. -- 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