From: deltacloud-devel-bounces(a)lists.fedorahosted.org
[mailto:deltacloud-
devel-bounces(a)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.