On Oct 23, 2009, at 11:07 AM, Markus Roberts wrote: > > > 2. If it is to be obligatory, we should probably update the > > comments as well. > > What comments? > > In the block-copied code there are comments that refer to yaml when > the associated code is using b64_zlib_yaml.
You've obviously got the code commenting down, so I'll let you cover that. > > 3. Would it make sense to use JSON (i.e. PSON) instead? > > I don't know. The facts were serialized as YAML beforehand. > If there is a desire to move all our serialization to pson, then I > guess > this one should move too. > > I don't have strong feelings on this, but 1) eyeballing it, the pson > is often looks smaller, 2) there are the same potential problems > with version incompatibility, though for various reasons the odds > are reduced. > > > 4. What are you thinking for a less hackish solution? POST? > > The issue is that POST doesn't fit the REST model. We're asking for a > rest resource of type catalog. But to be able to process it we need > the > facts. > Before that, the operation was done in 2 distinct operations: > * we were POSTing the facts, which were saved on the master > * we were GETting the catalog > > The issue was that in a multiple master system you could well post the > facts to master1 but ask the catalog to master2 which had no way to > fetch those facts. > Hence it was decided (although at that time I objected that the > request > size would be an issue) to merge those two operations. > > Of course we still can break the REST model, by returning the catalog > when saving the facts, but that feels ugly. > > I don't know of any brilliant resolutions. Luke and I are going to > talk about it some on Monday. That becomes relatively difficult given the way the Indirector is built. I can't remember ATM if the results of 'save' have to be nil or if they're ignored, but I suppose we could deserialize the results and save them, if they're non-nil. > > 5. Do you know if there's a way to have a format handler inherit > from > > another, so we don't have so much code duplication? > > That was my first concern too, I hate copy/pasting code. > Unfortunately there's no possibility without changing the way the > format_handlers are working which I wasn't ready to do for a 5 minutes > hack. > > I'm wondering if a proper solution would be to have a format (ie the > serialization system) and an encoding chain system (ie how we > transport > the values). > This way we could chose for every entity we transport: > * how it is serialized > * how it is transformed to be transported (ie compressed/ > uncompressed, > base64 encoded, nothing,...). Those transformations could be chained > so > that we could compress, then encode and son... > > I like that idea in general. Not sure how the details would play > out (or if adding inheritance would be an easier solution), but if > there's a clean/simple way to do this sort of filter chain I'm all > for it. > > > 6. Should this work on 1.8.1? For that matter, why didn't my PSON > > patch break fact-passing on 1.8.1? > > I don't know. > > It appears like it might break if there were a puppetmasterd running > on 1.8.1 and a client on >=1.8.5, but probably wouldn't because (at > a quick glance) it looks like we aren't serializing any of the > problematic types. -- The difference between scientists and engineers is that when engineers screw up, people die. -- Professor Orthlieb --------------------------------------------------------------------- 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 [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 -~----------~----~----~----~------~----~------~--~---
