[QUESTION] Is there already a centralized place where appstream information is submitted and stored?

[azubieta]

As it mentiones such a thing here: https://en.wikipedia.org/wiki/AppStream
"...which aims at creating an unified software metadata database, and also a centralized [...] user-contributed content database".

[ximion]

Eww, that is a very misleading sentence. I wonder where that OCS statement is from, I checked the current documentation and pages I am aware of, and there is no mention of OCS or any user-contributed content database anywhere.
That also isn't really the goal of AppStream. Currently, the very first sentence on "What is AppStream?" reads:

AppStream is a cross-distro effort for enhancing the metadata available about software components in the Linux and free-software ecosystem.

Which is still pretty accurate (although after looking at it, we should update the document a bit ^^)

AppStream metainfo files are created by upstream projects as described here (and with a more formal and extensive documentation on the XML format here as well). Those small XML files are shipped by the software project in /usr/share/metainfo/. From there, the XML metadata is picked up by other tools, most notably some kind of software delivery system, which in most cases is a Linux distribution.
Your distribution compiles the XML data into a bigger assembly of metadata, containing information on all the software components available in its repository that have AppStream metadata available. This data compilation is called "collection metadata" and also specified as XML or YAML, depending on your distribution.
That data gets shipped to the user by some method, where it is read by some kind of software center.
You can use the shared library, C/Vala/D/GIR bindings in this repository to do that (the library can also generate all types of AppStream metadata). In older times, on the client side we also had a Xapian cache of metadata, but nowadays that has been replaced with either no cache at all, or a GVariant-based one (depends on the software center what is used).

There is no real centralization in AppStream. There are plans to add more component-types to the metadata, e.g. one for themes and icon sets, but that's it. In any case, AppStream metadata (metainfo files) should always be stored with the project they belong to, and not be deployed from a separate place[1].

[1]: With minor exceptions, e.g. distros often provide the data for fonts, if font authors don't include it.

[ximion]

Some addition, after looking at the connected bug: If Your distribution supports AppStream (pretty much all distros do), accessing the data pool is damn easy. Doing it from C (and finding one component with a specific ID):

g_autoptr(AsPool) pool = NULL;
g_autoptr(GPtrArray) result = NULL;
g_autoptr(GError) error = NULL;
AsComponent *cpt;

pool = as_pool_new ();
as_pool_load (dpool, NULL, &error);
if (error != NULL) {
	g_printerr ("%s\n", error->message);
	return FALSE;
}

result = as_pool_get_components_by_id (dpool, identifier);
if (result->len == 0) {
	g_printerr ("Unable to find component with ID '%s'!\n", identifier);
	return FALSE;
}

cpt = AS_COMPONENT (g_ptr_array_index (result, 0));

You can also use as_pool_search to find a list of components via search terms.
Via introspection, you can also access this from Python, or use the Qt interface to use Qt/C++ to fetch the data.

[azubieta]

Thanks a lot for your response and for the snippet it was very helpful.