On Mar 30, 2009, at 11:49 PM, David Lutterkort wrote: > > 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.)
Yeah, this is why the process that retrieves items from the queue, for instance, isn't using a REST model for doing so. It just so happens that *most* of Puppet's network services are easy to model with resources, but clearly not all - 'status' doesn't make much sense, for instance. > > 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 ;) This messaging project is limited enough that I'm skeptical it's going to have a big impact on Puppet pervavisely using messaging suddenly, but I've always thought messaging was a much more appropriate means of sending a lot of information, especially reports. -- A gentleman is a man who can play the accordion but doesn't. --Unknown --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
