XDG directory structure

[Kevin Stange]

I just wanted to note that blist.xml is not a cache at all.  The
blist.xml is for storing additional metadata for buddies (meta-contacts,
aliases, settings, chats, last seen time, sort order) and actual stored
buddy lists for any protocol plugin that doesn't support server-side
lists, or perhaps in some cases where such lists are temporarily
unavailable.

Personally, I'm not in favor of this.  I don't feel it gains us very
much and it makes the configuration less portable on its own.  I
actually don't like the XDG standard because when I think about moving
information between computers I usually think about moving the data for
a particular application, and XDG actually makes that more difficult to do.

If we must do it, I would like to err on the side of assuming things to
be config data.  I would not waste effort on splitting out existing
config files into separate partially redundant pieces (like blist.xml
would be as proposed).  I think it's entirely over-thinking the problem
to consider splitting the contents of prefs.xml to try to break it into
multiple XDG classes.  All prefs are CONFIG.  They define how the
application behaves.

I would never classify something as XDG_CACHE unless I would be okay
with someone deleting it every time I restart the program.  If the
program needs the file to behave the same way after restarting, then
it's XDG_DATA or XDG_CONFIG.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20130610/0ec37acd/attachment.sig>