pnoltes commented on issue #515: URL: https://github.com/apache/celix/issues/515#issuecomment-1683808734
Concerning remote event admin. I think it is wise to start with a local event admin implementation, mostly following the spec (if possible) and only after that start on the remote event admin. I also expect that we still need to have a few discussion about the event admin. For example: - Are all events remote? Or is this a opt-in per event (e.g. with something like a `event.remote=true` property) or maybe with a special interface (`RemoveEventAdmin`). And do event handlers always receive local and remote events? - Will the `sendEvent` block until all event local and remote are processed? Will it have a timeout? - Will the thread or thread used by `postEvent` be configured / plugable? - Will remote events, pushed to event handlers on a single thread or multiple threads and is this configurable/plugable? - As mentioned by Peng, can event handler provide back pressure? If so is this a separate service interface? - Also as Peng mentioned, do we want to support QoS (best effort, reliable, etc) - Will the technology used for remote be plug-able and how? Maybe something like a distribution provider (as is used in Apache Aries, see https://aries.apache.org/documentation/modules/rsa.html) to make adding a new transport and serialization more easy. - Will discovery of remote event admins be supported? Or do we only support broker-like solution (MQTT, NATS, etc) (which does not need a discovery only a broker address). If discovery is supported, do implement an separate event admin discovery (like pubsub discovery) or maybe introduce a remote property store interface and implementation which can be used by remote services, pubsub and remove event admin to discover remote endpoints (note that endpoint both in remote service and pubsub are essentially nothing more than a discoverable properties set stored in a configurable path). - Do we add a wire protocol (as is currently done in pubsub)? This can be used to identify a protocol version (and thus detect if we are remote compatible), add a sync word (and maybe even detect byte order) and optionally provide metadata and/or message fragmentation. -- 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
