On Wed, 07.07.10 07:37, David Zeuthen ([email protected]) wrote: > > Interesting. So one one hand, you're saying "we're using the a > > Desktop-file format because there's so many parsers / API for it", yet > > with this move you break compatibility with a lot of them (in > > particular GKeyFile [1]). Embrace and extend? Anyway, it's a bit too > > clever... and, without getting all emotional... a bit inconsiderate > > for my taste. Not that I'm super-invested in this (I'm not planning to > > parse any of these files myself, anyway), but, any chance you can > > figure out a better way to do this? Thanks! > > In fact, turns out that valid desktop-files must not have multiple > keys with the same name; from > http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html > > Multiple keys in the same group may not have the same name. > Keys in different groups may have the same name. > > OK, so you actually said "closely follows"
I already downgraded that in the man pages a while back, after going through the .deskop spec and comparing it with my own parser. It now says "The syntax is inspired by XDG Desktop Entry Specification[1] .desktop files, which are in turn inspired by Microsoft Windows .ini files." There are a few more places where we deviate from the .desktop logic. For example: .desktop files tend to use ";" to seperate multiple data values in the same fields. We use spaces. BTW: GKeyFile says the following about multiple entries of the same name: "Note that in contrast to the Desktop Entry Specification, groups in key files may contain the same key multiple times; the last entry wins. Key files may also contain multiple groups with the same name; they are merged together. Another difference is that keys and group names in key files are not restricted to ASCII characters. " > Still, I think it might be nice to actually make it easy for GKeyFile > and other software to use your configuration files. Anyway, I'm not > terribly invested in this. Yes, that would be nice. But unfortunately I am not convinced this would really help the readability of the .service files. So I gave up on providing full compatibility (though I must admit I never thought about the GKeyFile parser, and now that I did I am a bit disappointed about the fact that GKeyFile is more DOM-like than SAX-like, if you understand what I mean). However, what I am thinking now would be a worthy goal is to provide one-way compatibility at least: i.e. make GKeyFile useful to write systemd unit files, although not all systemd unit files may correctly be read by GKeyFile. But yepp, it's a bit disappointing, and I am open for suggestions to fix this differently... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
