On Friday, 12 April 2013 09:30:27 CEST, Kevin Krammer wrote:
I guess in your case you could use $XDG_CACHE_HOME (defaults to $HOME/.cache) and an application specific subdirectory.
I would like to expand on this a bit -- the application in question does maintain an on-disk cache, and if a file size exceeds certain threshold, it is saved as a regular file on disk. However, there are a couple of reasons for not making this cache visible to the user: - There are no promises about the cache layout. It can change between the application versions without any further notice. Nothing else is expected to access it (think Akonadi's on-disk structures :) ). - The files are optionally compressed. - For technical reasons (the protocol provides hard guarantees about data immutability), the files shall really be read-only. If the user managed to e.g. open an office document from this private cache and saved it with some modifications, the appliocation would have to include extra checksumming, otherwise the next time user opens the "pristine attachment" from the IMAP server, they will actually see the modified data, and that's a serious bug. - Tiny attachments might be saved in e.g. a sqlite database, not in an extra file. This means that I cannot really use the already-present private cache and would have to come up with yet another custom location. However, the biggest problem is that this puts the burden on maintaining the lifetime of these temoprary files to the application which provides the data. As I've tried to show in my earlier mails, this application is in a very bad position to judge that (it has no idea whether the launched application still runs, etc), and all of the options which were described are heuristics at best (i.e. each one breaks in at least one situation). For these reasons I would like to avoid doing that. This is not meant to say that your proposal is wrong -- it might actually be the best option which is available *right now*. It's just that I would like to have a solution which somehow elliminates all of the problems I described. If only the "D-Bus activation" included an option for "throw away that file after reading it, prompt user for another name when modified,..." -- would something like that be feasible? With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
