Miloslav Trmač <mitr(a)volny.cz> writes:
2014-06-02 18:46 GMT+02:00 Stephen Gallagher
<sgallagh(a)redhat.com>:
> On 06/02/2014 02:51 AM, Marius Vollmer wrote:
> > Thomas Woerner <twoerner(a)redhat.com> writes:
> Thomas, maybe we can add a cancelDeployment() routine, but ensure that
> clients are aware that DeploymentUncancellable or something is an
> expected possibility.
Note that this has larger implications, notably the D-Bus server must not
block while performing a deploy() operation to be able to act on the
cancelDeployment() call.
Hmm, the server can not block in any case. It must always be able to
respond to things like GetActiveRoles etc.
> Is there anything more to these than convenience? E.g., can I
just
> > take the 'packages' properties and use it with the package
> > management API of my choice? If we already have a good UI for the
> > package management API, with highly polished progress reporting and
> > error handling, say, it is probably better to just use it instead
> > of trying to polish this API to the same level.
>
> Right, these are convenience. In the case of Cockpit, I'd expect you
> to use your own package-installation tool.
>
If the very first user of the high-level API decided to instead bypass it
and perform low-level operations, that’d be a *very bad* sign. Could we
instead learn from the cockpit API and add similar level of polish here?
Well, I was mostly asking to understand the API better. We don't have
any package or firewall management in Cockpit at this point at all. We
would very likely just call "deploy" and "start".