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.

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

Reply via email to