Proposal for a MIME mapping spec
keithp at keithp.com
Thu Jul 8 10:30:23 EEST 2004
Around 8 o'clock on Jul 8, Alexander Larsson wrote:
> Does it matter? Do we cater to broken implementations with a max line
Depends on if you expect humans will ever need to edit these files by hand
to solve some problem. If they're human editable, they should be
compatible with the "normal" text file conventions (can be made to fit in
80 column lines, provide for comments, etc.)
> Its sort of slow to wait for an app to read through all the desktop
> files to index them, plus it adds this complexity to all the
> implementors of the spec (and each one is gonna do it slightly
Of course, otherwise you guys wouldn't have suggested a cache in the first
place. I'm just trying to make it a 'real' cache instead of a
hand-generated duplicate database that will be out of date at times.
Do you think there will be multiple implementations of this low-level
database construction code? Seems like we could find a way to share this
part; certainly the 'update-desktop-database' program should be shared; if
that functionality was just stuck in a shared library it could be called
when needed by the applications themselves.
> And anyway, storing caches for system settings in your homedir strikes me
> as wrong.
Yes, this isn't an ideal situation. Fontconfig solves this by having the
'update cache' application create global shared cache files which are
augmented by the per-user cache files that cover the bits which are not
correctly cached in the global file.
I think the fontconfig techniques have worked out reasonably well, except
for the fact that the cached data cannot be shared across processes (which
leads to a rather huge amount of memory used per application). I'm
scheming about how to fix that though by using a binary cache file format
that can be mmap'ed read-only. Someday soon, I hope.
The good news is that except for a few early bugs, I haven't received any
complaints about caches out of sync or problems getting new fonts
installed. Huge win.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040708/4e744538/attachment.pgp
More information about the xdg