2014-06-03 9:19 GMT+02:00 Marius Vollmer <marius.vollmer(a)redhat.com>:
Stephen Gallagher <sgallagh(a)redhat.com> writes:
> On 06/02/2014 02:51 AM, Marius Vollmer wrote:
>>> reconfigureRole(a{sv}) # reconfgure role with new config settings as
>>> key value pairs
>>
>> A role could specific which program to run to do a interactive
>> configuration. For terminal, for a graphical session, and for
>> Cockpit (by specifying a module that Cockpit will load).
>
> Out of scope. We don't want the API to be interactive to that level.
> It introduces too much complexity.
>
> The API will be pretty much static, so the UIs should be able to just
> do whatever interaction they want and then push down the final
> results.
Sure, I was actually going in the other direction, but I wasn't clear:
_Instead_ of reconfigureRole (which can't be used generically), the
generic role description would just say what program to run for a
limited number of session types. FreeIPA would say "ipa-server-install"
here, and Cockpit would offer to run that in a terminal.
Nonononono. You might just as well define that IPA.defineRole is
equivalent to (ipa-server-install $the_value_of_param_a
$the_value_of_param_b), and so on for every operation, ship an XML file
with these definitions (and perhaps one more file for X/Wayland UIs if
anything provided them), and drop the D-Bus API completely, then.
I think we do want the API to be used generically, by tools that *can* be
generic. E.g. store the role configs in a configuration management system
as files, and have exactly the same D-Bus call (or command-line utility) to
deploy them, perhaps in the shell-script world something like
for f in /etc/our-site-role-configs/*; do server-role deploy
--kickstart-like $f; done
Good UI can’t be generic and I basically don’t think we can avoid writing a
Cockpit-and-roles-specific UI if we want any non-CLI UI at all. (i.e.,
cockpit-specific but not-roles-specific wouldn‘t work at all, and
roles-specific but not-cockpit-specific mostly wouldn’t work either).
Overall, I think Stephen’s proposal to let the operations accept a
fully-prepared configuration (like the a{sv} above), is a reasonable
approach at the API level.
Mirek