On 07/21/2016 11:43 AM, Petr Spacek wrote:
On 20.7.2016 19:25, Ben Lipton wrote:
On 07/20/2016 12:21 PM, Simo Sorce wrote:
On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote:
On 07/20/2016 10:37 AM, Simo Sorce wrote:
On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote:
On 07/20/2016 06:27 AM, Simo Sorce wrote:
On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote:

I have updated the design page
with my plan for implementing user-configurable rules for
data into certificate requests. In brief: we will use Jinja2
templating. Data rules (which map individual data items) and
rules (which group them into certificate fields) will both be
of Jinja2 markup. The formatting process will be as follows:
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?

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.
Besides this nit,
sounds reasonable. I like how it prevents bad data from template-injection.

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.
, 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 

+1, I think option B was a bit of premature optimization.

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
<jchol...@redhat.com>  - 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!

Thanks for the feedback, and the kind words!

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to