[AppStream] Using AppStream for "Server Applications", Cockpit

[Marius Vollmer]

Matthias Klumpp <matthias at tenstral.net> writes:

> I have been thinking about adding a component-type "daemon" or
> "service" to AppStream for a while, which would cover background
> services like webservers, question is whether you could use something
> like that for your use-case, [...]

Yes, this makes much more sense than type="server-application".

Content-type "service" would be for a systemd service?  Cockpit could
work very directly with that.

> This will be tricky, I assume (as web server admins will also want to
> install services that are *not* web-facing, like MySQL or even stuff
> that would be a generic-type component, suhc as Python).

Cockpit can offer to install console-application components, and then
explain how to get to a shell (either ssh or using the builtin terminal
emulator).

What about adding component-type "cockpit-application"?  This would be
for components that add their UI to Cockpit.  And then we make little
UIs for setting up MySQL, PostgreSQL, FreeIPA, etc.  I have a plan to do
this for FreeIPA.

So Cockpit would filter by type and include those that make sense for a
remote session in a web browser: console-application,
cockpit-application, and service.

We might need to add some categories maybe, but for now I think I can
ignore categories.  If someone makes a game for Cockpit, why not.  No
need to filter that out.  Let's see how many console-applications there
are already... :-)

> At Debian, only the data the respective frontend requires and only the
> data of enabled sources is downloaded and installed.

This is explained in DEP-11, right?  (I noticed the sentence "On servers
this file is not really required." :-)

>>  - In this modern world, we will have to have a container story.  If
>>    AppStream is the way to go, how do you feel about getting containers
>>    in it as well?  I know Flatpak uses AppStream, and I'll make sure
>>    that Server Applications via Flatpak will totally be possible, but
>>    maybe we also need to include Docker, System Containers, etc to the
>>    party.  Has anyone thought about this already?
>
> I don't really know what you mean by that. AppStream, as metadata
> format, doesn't care at all which bundling system is used.

AppStream needs to be able to say how to acquire the component, and we
might need to extend the collection metadata for containers that are
pulled from registries.

Also, after we have the component, the client needs to know what happens
next, no?

For example, a desktop-application component is known to have a Desktop
file in it that makes it appear in some launcher menu.  A
cockpit-application component has a Cockpit plugin manifest in it that
makes it appear in the Cockpit menus.  A service component has a systemd
unit file in it, so it can be managed with systemctl.  A font install
something can then be found with fontconfig, so Cockpit ignores that.

A container image (or Nulecule atomic app, ...) might need a different
way to manage it, so we might need new component types.

I want to concentrate on "System Containers"[0] first, which present
themselves as systemd services.  I also want to make it possible for a
system container to bring a Cockpit plugin, and then they might be
component-type "cockpit-application".  So nothing new just because they
are containers.  I think this might be similar to how a Flatpak is a
desktop-application and not some new component type, right?  Let's see.

[0] http://www.projectatomic.io/blog/2016/09/intro-to-system-containers/

> It would be awesome to know what exactly you are planning, so can you
> maybe give some details on what you want to do with AppStream
> specifically?

I try to keep this up-to-date:

    https://github.com/cockpit-project/cockpit/wiki/Server-Applications

You might think of this as "GNOME Software running in a browser".  So we
want to discover available applications via AppStream, and learn enough
about that application to know how to manage it further inside Cockpit.