[RFC] std.mime design

[Johannes Pfau]

I've been working a std.mime module for some time now, and I'd like to
get some feedback on the API design:

Here's the documentation for the current version:
http://dl.dropbox.com/u/24218791/d/src/mime.html

The freedesktop.org part is complete, the windows part will be added
soon (the public API won't change) and it seems there's no API on OSX to
get a MIME type for a file, so OSX will have to use the freedesktop.org
backend.

Here are some specific questions regarding the API design:

* I think it's useful to have a global default database which is
  currently implemented through the global functions like getMimeType,
  getByData and getByName etc. However, the windows MIME support is very
  simple and only supports getting the mime type by file extension. So
  getByData, resolveAlias, typesEqual, isSubclass etc won't work on
  windows. Should those functions be moved to a FDO specific backend?
  Should the DataBases be classes so that FDODatabase can be a subclass
  with additional functionality and user code can check which backend is
  used?

* Is it useful to have methods to load and unload additional databases
  to be used with the global functions? This would require all global
  functions to take a lock(ReadWriteMutex). Is it worth it?

* If additional databases could be added to the default database
  lookup, which one should be preferred? For example, if a FDO database
  is loaded on a windows system, should the windows database or the FDO
  database be preferred?

* It is of course always possible to load a FDOCache manually and use
  it's instance methods. The preceding questions only affect the global
  functions.

* getTypeFromFS currently doesn't throw if the underlying filesystem
  doesn't support extended attributes. Consider an application reading
  a directory with 10_000 files. The app wants to check if the files
  are music files. If someone explicitly set the files content type,
  that information can be trusted. So the app calls getTypeFromFS on
  all 10_000 files. Now if the filesystem didn't support extended
  attributes and getTypeFromFS did throw, 10_000 exceptions would slow
  down the application a lot. It's also not possible to say:
  getTypeFromFS wasn't supported on file 1, so it won't be supported
  on all other 9_999 files. Those files could be part of a different
  filesystem, and that's hard/impossible to check. So is it OK in this
  case not to throw an Exception on a ENOTSUP error?

* FDOCache currently uses strings instead of MimeTypes. I guess that
  should be changed? FDOCache needs some of these functions to return
  strings though, so I'd have to write wrapper functions taking &
  returning MimeTypes.

* Some of the functions names are not optimal. Thoughts?

* Feedback on the documentation is also appreciated.

And a small implementation issue:
I have to read strings from the mime.cache database files. How can I
prevent to!string(char*) from reading past the end of the data buffer if
a malformed file is loaded? Is there something like a cross-platform
strnlen?

-- 
Johannes Pfau