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

[Marius Vollmer]

Matthias Klumpp <matthias at tenstral.net> writes:

> Would be a component-type, and yes, it would affect anything that can
> be started via systemd (which would also include SysV-init scripts).

Sounds good.  I'll keep this in mind as I go forward.

>> What about adding component-type "cockpit-application"?
>
> [...] But, there are ways AppStream can deal with this. Depending on
> the nature of what "Cockpit integration" actually is, a component
> could:
>
>   * Provide it as a new provides type, in case it is some kind of
> interface, e.g. by adding <provides><cockpit>blah</></> to a
> component.
>
>   * Be a separate "addon" type component extending the actual
> software, in case cockpit integration can be an usually is separated
> out from the main product. In that case, the addon would either extend
> Cockpit itself or the main software (e.g. MySQL). In the latter case,
> some new AppStream tag would be required to split addons into groups
> (on my todo list as addon_class tag).

Yes, I think <provides> and "addon" should be enough.  Cockpit _can_ be
treated as if it were on the same level as GNOME and KDE, but treating
it as a application with extensions is more realistic.  Also, Cockpit
can run locally in a desktop as a "webapp", and it is feasible that
GNOME Software actually installs addons for it.

> [containers]
>
> What the AppStream collection metradata does, however, is giving
> pointers on how to query the install/remove instructions from other
> systems. E.g. it contains a package name to allow software centers to
> install software via PackageKit, or a Flatpak bundle ID to install it
> from a Flatpak repo.

I think this would be the same with containers: the collection metadata
would give a image name, and the components-origin identifies the
registry somehow.

> So, what we might need is a new <bundle/> type in the AppStream
> collection spec for the specific bundling systems / repositories.
> But it could be that I am misunderstanding the problem here.

I think this makes sense.

(Why is pkgname not a bundle type?  Historical reasons?)

> Looking at this, it actually appears like we wouldn't need to add much
> to AppStream except for the "service" component type and maybe a
> couple of new bunding system types, which would be quite neat.

I agree!

> I'll need to try out Cockpit to see how it works and get a clearer
> picture,

Tell me if you need help.  Start here if you want to run it:

     http://cockpit-project.org/running.html

A quick summary of the interesting bits of the Cockpit architecture.

Cockpit builds its UI by loading all manifest files from

    /usr/share/cockpit/<dir>/manifest.json

Each directory with a manifest file is a "Cockpit package" or "Cockpit
plugin" and usually contains some HTML files plus JavaScript and CSS.

Most of the packages are like applications: They put themselves into one
of the Cockpit menus and Cockpit then loads the main HTML file into a
frame in the browser.  Examples are Storage, Networking, Containers,
Terminal, well, everything you see in the menus.

Some packages are like libraries and provide files that are loaded into
the frames of other packages.