> > 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. > > > 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. > > 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. -- Markus --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
