Kami commented on issue #1786: URL: https://github.com/apache/libcloud/issues/1786#issuecomment-1660342260
Yeah, I think ``libcloud.queue`` / ``libcloud.queing`` API would make sense. Since queuing APIs are usually quite poll heavy (at least for reading / retrieving messages), I think it would also make sense to expose async API in addition to the sync one. This would also make it a first abstraction in Libcloud which would native expose async APIs - which makes a lot of sense in this day and age. I know that some library users build their own async primitives on top of other Libcloud APIs which don't expose async methods. Ideally the next step would be a proposal in a form of a PR which implement the base API. Implementation for at least 2-3 providers is also a good idea to make sure that the base API is generic enough and not biased towards a single provider (that's how we approached other APIs as well - base API + 3 driver implementations). -- 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: notifications-unsubscr...@libcloud.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
