AppStream 0.9 Brings Many Changes, Breaks API/ABI

[phoronix]

Phoronix: AppStream 0.9 Brings Many Changes, Breaks API/ABI

Version 0.9 of AppStream is now available. As a refresher, AppStream is a FreeDesktop.org specification backed by multiple major Linux distributions as a cross-distribution effort of standardizing Linux component metadata...

http://www.phoronix.com/scan.php?page=news_item&px=AppStream-0.9-Released

[gens]

a horrible glib XML mix for designating simple metadata ?
this is something that some company would churn up to quickly hack together a "feature"

no thx

[Ericg]

a horrible glib XML mix for designating simple metadata ?
this is something that some company would churn up to quickly hack together a "feature"

no thx

It's standardized, easily parsable and fit the developer's needs/goals/desires. If you wanted something different then maybe you should've started the work a few years, like Ximion did. But, as always, the people doing the work get to decide how the work is done.

[zanny]

AppStream has the potential to make Linux packaging finally distro agnostic. If you distribute your stuff via xdg-app, use appstream as the installer backend, and specify dependencies by descriptors, you never need to build another set of .deb .rpm and .tar.xz packages again. And anyone can make a software store / center for it, providing their own distro agnostic repositories, and still interact with the distro specific packaging.

If that actually happened, we might almost have a legitimate desktop for your mother, for once.

[gens]

It's standardized, easily parsable and fit the developer's needs/goals/desires. If you wanted something different then maybe you should've started the work a few years, like Ximion did. But, as always, the people doing the work get to decide how the work is done.

Ximion ?
do you mean ximian ?

anyway no standard is better then a shitty one
think of it this way:
many more people will use the standard then there are people developing that standard
so putting more work in to the standard results in less overall work when the usage of said standard is being done

and i did suggest a better format for the metadata back when i first found out about this App* crap
(key: value with some extensions or just INI)
response was along the lines of "there are already libraries that parse XML"
considering that humans are the ones writing this metadata, that is a poor response (see the logic above as to why)

edit: mind you that this is to be used indefinitely in the future, not just a few months and good bye

edit2:
writing these standards takes a lot of testing and other work
i'l just ignore this gnome thing, it's much better to ignore all gnomedesktop.org things then care about it

[finalzone]

Ximion ?
do you mean ximian ?

https://github.com/Ximion

https://github.com/ximion/appstream

[Ximion]

[...]
and i did suggest a better format for the metadata back when i first found out about this App* crap
(key: value with some extensions or just INI)
response was along the lines of "there are already libraries that parse XML"
considering that humans are the ones writing this metadata, that is a poor response (see the logic above as to why)
[...]

Sorry, but you are very wrong. INI files lack a lot of features XML has and which we need in AppStream.
First of all, you confuse "AppStream distro metadata" (the stuff that we ship to users via the repository) with "AppStream upstream metadata" (often called MetaInfo, or AppData, which is some XML upstreams ship).
Initially, only the distro metadata existed, and XML was the format of choice because it allows expressing lists, multiple properties per tag, nested entries (essential for e.g. release data and screenshots) and most of all XML allows extending the format easily without breaking backwards compatibility.
Take a look at this example metadata. You can not express that in an INI file without it becoming totally unreadable and also hard to parse. Having an aggregate of this would be even more insane, and if you split this into multiple smaller files, it will hurt performance (loading thousands of small textfiles is not that cheap).

So, for distro metadata, XML is absolutely the right choice. Debian went with YAML for historic reasons, which provides all features we have in XML, but YAML structure is not as easily extensible without breaking backwards compatibility, compared to XML. In future, we will take great care of that.
For upstream metadata, XML might not be awesome, since humans writing XML is always a bit annoying, but because XML is so easily extensible and because we need XML features and because AppStream distro XML was already XML, using XML for metainfo files makes a lot of sense too and is a logical and sane choice (wasn't my choice, btw ^^). It also contributes to a consistent specification, which can easily be understood by people new to it (introducing new file-formats and having to translate between them is really not great).

So, you can believe me that there is a lot of thinking behind the specification and how it might evolve in future, and that no decision was taken without a reason.

Talking about GLib: For a C programmer, GLib is pretty much the best thing that happened on earth ;-) I provides nice helper functions and a basic framework to write maintainable applications in C. As a result of using GLib (and GObject), libappstream has bindings to any scripting language and can be consumed by e.g. Vala. Keeping API and ABI stable is relatively easy with a C library, so using that is a good choice (there even exists a second C library, libappstream-glib, implementing the spec and some extensions GNOME-Software uses which you can choose from). For people who like C++ and Qt more, there is a libAppStreamQt library available, so everyone can use their favourite tool.

Last but not least: AppStream is not a GNOME project - it was started by people from pretty much every desktop and distribution, is maintained by a KDE developer and driven by people from KDE, Elementary and - of course - GNOME, which did a great job in pushing it forward and evolving it with the development of GNOME-Software.

[zanny]

considering that humans are the ones writing this metadata, that is a poor response (see the logic above as to why)

Most of this metadata isn't being human written on Debian, its being extracted from app packages. And if you are hand writing metadata, use YAML, its a super readable and writable format that beats arbitrary INI custom configs.