jason810496 commented on PR #49938: URL: https://github.com/apache/airflow/pull/49938#issuecomment-2844782435
> What would happen if we want to add a new provider to support common.messaging? Should we release a new common.messaging provider version? That makes no sense and is completely against the "genericness" of it - also it prevents others from developing their `common.messaging` capable provider independently. I see—I overlooked the general-purpose of the common provider. In that case, having a `type` or `provider` argument in the constructor might not be a good idea. > We just need to be very clear - for each implementation - what is the format of the `queue` URI. I don't think this will be universally standard - because basically there is no universal standard for globally recognized URI format for message queues. Or maybe there are 5 competing standards or smth.. I think - similarly as in case of connections (where we have AIRFLOW connection URI form - for good or better) this should be done this way. > And even better where we include the regexp directly from sources to the documentation: Looks great! The detailed documentation really helps clarify the ambiguity around the `queue` URI, especially with the inclusion of regex examples and how the parsed values are passed to the trigger constructor. > we might consider supporting "json" form of the queue on top of the URI. URI has certain limitations (especially around encoding) and eventually we settled on both URI and JSON formats supported for connection for that reason. As for the JSON format—perhaps we could have a `queue_type` for matching and an `extra` field for provider-specific kwargs? Just a rough idea, but JSON format also works for me. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
