On Thu, 2009-03-19 at 23:06 -0400, Ethan Rowe wrote: > I'm a newcomer, so feel free to ignore me. But, if RESTful design has > become an increasingly important consideration in interactions between > client and server (and it's my impression that it has), I think you > might find that it fits better in this case to: > * have the server issue a 202 Accepted response, with an response entity > containing: possibly a URL to periodically check for results; possibly > an estimate of time before the new resource is available > * have the client periodically consult the relevant URL until the data > is available
I've spent some time recently banging my head against the limitations of REST for oVirt - the assumption that REST makes that everything is a resource on which you execute a fixed number of actions is really nice if you are dealing with something that looks like a resource fairly naturally, but gets very annoying when that assumption is broken (like VM's which can be started, stopped, shut down etc.) We are in the process of implementing API's for oVirt now based on QMF[1], a small layer on top of Qpid, an open source message bus; the programming model of QMF is pretty nice since it abstracts all the messaging etc. away nicely. From a coding point of view, you are dealing with objects, call methods on them etc. and QMF/Qpid take care of distributing changes throughout the messaing infrastructure. Architecturally, everybody is a client connecting to a central broker, even the server on which the objects really live; the logical client gets a view of those objects, calling methods on them causes some method on the server to be executed etc. We're using that to connect various virtualized hosts together - each host is the 'server' for the VM's that are running to it, and a client using the QMF API gets to see a collection of all the VM's on all hosts, can start/stop etc. them without the need to connect to individual hosts. I am mostly mentioning this because it's an important new way of connecting infrastructure together, and radically different from all the other approaches I have seen. If anybody's interested in diving into this a little more in the context of puppet, feel free to contact me. A rough idea would be to have each client serve its facts and its current catalog over QMF and have the puppetmaster expose appropriate methods to retrieve an updated catalog. Of course, this is not directly connected to the issue at hand (speeding up storeconfigs), but it's got to do with messaging ;) David [1] http://qpid.apache.org/qpid-management-framework.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
