<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 07/21/2016 11:43 AM, Petr Spacek wrote: <blockquote cite="mid:60f90568-e517-8516-7c93-491d9bd20758@redhat.com" type="cite"> <pre wrap="">On 20.7.2016 19:25, Ben Lipton wrote: </pre> <blockquote type="cite"> <pre wrap="">On 07/20/2016 12:21 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote: </pre> <blockquote type="cite"> <pre wrap="">On 07/20/2016 10:37 AM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: </pre> <blockquote type="cite"> <pre wrap="">On 07/20/2016 06:27 AM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi, I have updated the design page <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/Automatic_Certificate_Request_">http://www.freeipa.org/page/V4/Automatic_Certificate_Request_</a> Gene rati on/Mapping_Rules with my plan for implementing user-configurable rules for mapping IPA data into certificate requests. In brief: we will use Jinja2 for templating. Data rules (which map individual data items) and syntax rules (which group them into certificate fields) will both be snippets of Jinja2 markup. The formatting process will be as follows: </pre> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> <pre wrap="">I've finally found some time to read the sub-page Mapping_Rules and for me it is kind of hard to follow. It would not be understandable without this e-mail and the blog posts (BTW the blog articles are among best I have seen!). Most importantly, the explanations in brackets above ["Data rules (which map individual data items) and (which group them into certificate fields)"] are missing in the wiki page itself :-) Could you fold relevant parts of the e-mails and blogs back into the wiki page so it is self-contained?</pre> </blockquote> Very good point. I may have been assuming knowledge of the whole design when reading this document, which doesn't make sense. I did some cleanup, plus added some more detail about how things work in the implementation I just sent out for review. I hope that will clarify things somewhat. <blockquote cite="mid:60f90568-e517-8516-7c93-491d9bd20758@redhat.com" type="cite"> <pre wrap=""> Besides this nit, <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation">http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation</a> sounds reasonable. I like how it prevents bad data from template-injection.</pre> </blockquote> That's what I like about it, too. It does turn out to make things a little tricky when it comes to writing rules that won't render if the data they depend on is unavailable. (Because instead of rendering individual rules which we can drop if they're missing data, we build one big template that has to handle missing data correctly on its own.) I think it's probably still worth it, though. I added this to the "Alternatives considered" section of the above document. <blockquote cite="mid:60f90568-e517-8516-7c93-491d9bd20758@redhat.com" type="cite"> <pre wrap=""> Regarding <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A">http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A</a> , I prefer Option A with separate object for each helper. It is somehow cleaner and it might be useful to use distinct object classes for each helper etc.</pre> </blockquote> +1, I think option B was a bit of premature optimization. <blockquote cite="mid:60f90568-e517-8516-7c93-491d9bd20758@redhat.com" type="cite"> <pre wrap=""> API for ipa cert-get-requestdata sounds good. API for ipa cert-request makes sense to me as well. In any case I would recommend you to consult API design with Jan Cholasta <a class="moz-txt-link-rfc2396E" href="mailto:jcholast@redhat.com"><jcholast@redhat.com></a> - he is our API custodian. BTW I very much like "Alternatives considered" sections, we should have this for each design! Good work, I really like the dutiful analysis! </pre> </blockquote> Thanks for the feedback, and the kind words! Ben </body> </html>