On 30/11/09 19:33, Luke Kanies wrote: > On Nov 30, 2009, at 8:27 AM, Markus wrote: > >>>> >>>> It could be even simpler, I think. >>>> >>>> * Switch to issuing a POST everywhere that we presently issue a GET, >>>> with a fallback to GET if the POST is rejected (405) or even better >>>> based on the api version for mixed system backwards compatibility. >>>> >>>> * Switch to accepting both POST and get where we now accept only >>>> GET. >>> >>> >>> I'm comfortable with this, and I like the idea of the server being >>> agnostic about post/get. >>> >>> It only gets us halfway, though - we need a POST to return the >>> results >>> of another query entirely (i.e., the POST of the Facts should return >>> the results of a GET of a Catalog). How would we do that? >> >> I'm envisioning something much simpler. We presently map requests >> on to >> HTTP GETs; instead, we should map them onto HTTP POSTs. That means >> we've got unlimited payload size in either direction, but otherwise >> nothing changes. > > Again, that doesn't solve the real problem - I want a Facts post to > return a Catalog. How, as the client, would I tell the server that? > > Or do we just always return a catalog when someone posts facts? That > seems a bit overkill.
Call me stupid, but I don't see why you can't POST the facts to the catalog indirector. Each time you need a catalog you must provide the more current facts you can, failure to do so (ie using GET) will use the cached facts from the <insert here your favorite cache method including memcache/node mgr or whatever>. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
