On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote: > On 07/25/2016 11:07 AM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: > >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > >>> On 07/25/2016 05:07 AM, Simo Sorce wrote: > >>>> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > >>>>> Anyway, my main grudge is that the transformation rules shouldn't > >>>>> really > >>>>> be stored on and processed by the server. The server should know the > >>>>> *what* (mapping rules), but not the *how* (transformation rules). The > >>>>> *how* is an implementation detail and does not change in time, so > >>>>> there's no benefit in handling it on the server. It should be handled > >>>>> exclusively on the client, which I believe would also make the whole > >>>>> thing more robust (it would not be possible for a bug on the server > >>>>> to > >>>>> break all the clients). > >>>> W/o entering in specific +1 as a general comment on this. > >>>> If it can be done on the client, probably better be done there. > >>>> > >>>> Simo. > >>>> > >>> My thinking was that while the CSR generation must be done on the > >>> client, the retrieval and formatting of the data for the CSR should be > >>> done on the server, so that the functionality is available to all > >>> consumers of the API (ipa command-line, certmonger, Web UI, something > >>> else?). I imagine it would be relatively easy to move the formatting > >>> stuff into the ipa CLI, but all the other clients would then need an > >>> implementation of their own, and so we'd need to worry about > >>> interpreting the templates and generating CSRs in multiple different > >>> languages. It's true that as it stands a bug on the server could break > >>> all the clients, but on the other hand there's only one implementation > >>> to maintain, rather than a different one in each client. > >>> > >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more > >>> of a problem because clients are easier to update with bugfixes than the > >>> server? Or maybe the preference for the client is for scalability > >>> reasons? Could you tell me more about why you prefer a client > >>> implementation? > >>> > >>> (And yeah, everything here carries a disclaimer of "I probably can't > >>> make any large changes in the remaining 3 weeks of my internship," but I > >>> think it's still good to know and document what the limitations of the > >>> current implementation are.) > >>> > >>> Thanks, > >>> Ben > >> You do not want to have to upgrade the server because tool foobarx > >> became suddenly the most used. Client tools may change over the time as > >> well, so if you try to generate stuff on the server you may end up > >> having to support multiple version with little way of knowing which > >> version that is. > >> > >> It is true that multiple client would have to implement "something", but > >> that something could be a python library+binary that other tools/script > >> can call or pipe through as needed. > > Note, from my pov the code should be more or less the same except it > > would run on the client rather than the server. Templates would be > > delivered via the same package that delivers the tool/module and admins > > would have the option to add more locally, though I am not against > > sharing templates via the server if we think that is a good idea in > > general (but the same issue vs tools changing and rendering templates > > broken with one or another version remain). > > > > Simo. > > > Ok, I definitely see your point here about making it easier to support > the shifting versions of the helper utilities. Pulling the formatting > out into a standalone binary that could be used by different clients > seems achievable. The Web UI wouldn't be able to use it, I guess, but as > of now there's no web UI for this feature anyway. I'll make sure this is > at least documented as a desirable modification.
Note, that the same tool *could* be used server side in the UI, should it be desirable. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code