From: deltacloud-devel-bounces@lists.fedorahosted.org
[mailto:deltacloud-
devel-bounces@lists.fedorahosted.org] On Behalf Of David Lutterkort
...
Very cool; the world will definitely be a better place with agreement on API's in those areas.
In the very big picture, I am hoping that we'll get to a place where we have API's for all the infrastructure building blocks that are event-driven (i.e., backed by messaging) rather than inherently request-based API's. With Qpid/QMF, we have a solid foundation for such API's. In a message-based world, there'll always be a need for bridging request-driven API's into the event-driven world (e.g., there's little we can do to make Amazon's API's go that way), but there are plenty of services that we can change to support event-driven interaction natively.
For application writers, life would be much easier, and we'd save each application from implementing its own caching/updating logic to track state etc. That logic would either reside in the services themselves, or in the poll/event bridges.
[IH] I agree on the QMF side - we need to provide the more powerful two-way (which allows event driven) api. One could still use the web service to poll for the state, but the solution should support sending events as well (so we should plan an API that supports both one-way and two-way modes in the one-way mode there should be an easy way to poll for the queue of events for example.