Fedora 22 Will Likely Make Apps In The Software Center Have AppData

[RahulSundaram]

Red Hat is trolling us again. They could use old good conf files or JSON - but why make things easy?

1) This isn't a vendor driven effort

2) Read http://people.freedesktop.org/~hughsient/appdata/

"AppData is a subset of the AppStream schema, which is also XML. "

AppStream is a cross distribution effort and not vendor specific either.

[gens]

1) This isn't a vendor driven effort

2) Read http://people.freedesktop.org/~hughsient/appdata/

"AppData is a subset of the AppStream schema, which is also XML. "

AppStream is a cross distribution effort and not vendor specific either.

that does not make XML a good decision

[RahulSundaram]

Again openSUSE is there and does that with it's Community Repositories feature in YaST, and the openSUSE-Guide, and http://software.opensuse.org can be easily used to fill in the gaps with other repositories. Now don't get me wrong I like Fedora but Fedora isn't really designed for that usecase, while dozens of easily added and managed repos is openSUSE's big thing.

To be fair, Fedora makes it pretty easy to add third party repositories with dnf/yum and copr.

https://fedorahosted.org/copr/wiki/HowToEnableRepo

It just doesn't handle codecs etc in the same way due to legal concerns

https://fedoraproject.org/wiki/Software_Patents

[Sonadow]

that does not make XML a good decision

It's upstream's call, so i'll stick with it for better or for worse until a suitable alternative comes along and catches Freedesktop's eye.

[RahulSundaram]

that does not make XML a good decision

Sure. AppStream might have choosen XML in the first place but obsessing over a file format decision that users aren't even going to see is a silly thing anyway. All you are doing is being a arm chair critic.

[anda_skoa]

that does not make XML a good decision

The choice is also affected by historical context.
While JSON is very popular and thus widely supported right now, it has not always been outside the JavaScript world.

XML, on the other hand, has been around for so long that there is virtually no technology stack that does not have an established, well tested, XML parser, potentially even higher level tools like code generators or persistence frameworks.

Cheers,
_

[gens]

still, XML ?
and yes, bickering over the format
all that this metadata declaration standardization effort is is a set of variables and a format

variable: content

variable: multiple, content

variable: "some string"

variable:
"multi
line
string"


a few corner cases that are not entirely absent in XML
not too hard to write a proper parser
human readable/writeable


but ye, whatever
i don't care

[anda_skoa]

It is always possible to specifiy a custom format, but requiring each participating party to write respective custom parsers can slow down the uptake.
Using an established and well supported base technology does have its benefits.

Cheers,
_

[gens]

i'm sure there are many parsers for json and for the format i suggested here
.desktop files also have open-source parsers

despite all that, writing a simple parser is simple
even writing a complex parser is simple if you use ragel or some other parser generator

not to mention that there will be many more people writing these things then people making/incorporating parsers for them


teach a man to fish...

[anda_skoa]

i'm sure there are many parsers for json and for the format i suggested here

JSON might have been the choice if this would have been created nowadays. As I said:history context.

.desktop files also have open-source parsers

True, not sure though if there is a specified nesting syntax, not very common in INI style files.

despite all that, writing a simple parser is simple

Sure, but not having to write one is even simpler.
As I said, improving uptake speed by using established technologies.

Cheers,
_