(Pedantic: fontconfig isn't object oriented.)
Aside from that: I'm not quite sure what you're asking. As Akira pointed out, MD5 is only used for directory names. On Fri, Jun 20, 2014 at 6:56 PM, L. A. Walsh <fonts@xxxxxxxxx> wrote:
Behdad Esfahbod wrote:
Why would a *temporary* cache be part of a public API that cannot be changed?On 14-06-20 02:13 PM, L. A. Walsh wrote:
On x86_64 machines, when addressing the cache, if all types were
listed as being "[u]int{32,64}_t", when wouldn't the cache format
on such machines be identical whether you were running in 32-bit
or 64-bit mode?
The separate caches are mandated by the public API that cannot be changed anymore
I'm more than a bit astonished that someone would think that a cache should
be part of a public API? Why would anyone do that?
Where is the object oriented design? How can the format be upgraded or
improved?
Who (or what product) is a "consumer" of the API? Why would
some other application outside of the library need fixed access to
an internal cache format? Are you saying that if someone finds a way
to create a security exploit using this public cache API that cannot change,
then there would be no way to fix it?
Caches are usually (in my experience, always), private data stores that
speed access. Example -- squid has a cache, but it would never be part of a
public API, as a cache, by definition, is supposed to be something that is for
"fast and private access". The kernel has multiple caches -- but in a
20+ year old product, they don't have any public API to internal caches that
would ever be called stable. Why does a font library need to publish a fixed
cache format?
_______________________________________________
Fontconfig mailing list
Fontconfig@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/fontconfig
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
