dominikriemer commented on PR #2476: URL: https://github.com/apache/streampipes/pull/2476#issuecomment-1967649269
Hi @obermeier well, that's a good question ;-) I guess the short answer is it's supported, but incomplete. Long answer: The `preferredProtocol` can be defined at installation time as an environment variable. In the messaging settings in the UI, the prioritized protocols can be sorted. Any extension service can define its `supportedProtocols` (this can even be defined individually for each pipeline element). There can be one or more supported protocols. So when using the pipeline editor and connecting two pipeline elements, the system also checks for a `protocol match`. E.g., when you have two extension services with one service supporting NATS and Kafka and another service supporting Kafka, NATS and Pulsar, the system would select the protocol depending on the priority defined in the UI. What makes this feature incomplete is that changes in the UI will only affect newly created pipelines. Existing pipelines use the protocol selected during pipeline creation. Feature completeness would be achieved by migrating all existing adapters and pipelines in case the protocol priority is changed. I'm a bit unsure what to do with this feature: On the one hand, it can be useful in the future when thinking of edge-cloud scenarios, e.g., pipelines with pipeline elements which exchange data over local nodes (which could be something lightweight like MQTT and NATS) and other pipeline elements supporting Kafka and Pulsar for more centralized, heavyweight processing. On the other hand, removing the dynamic selection would simplify the system and selecting a global protocol add installation time would be permanent. What do you think? -- 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...@streampipes.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org