+/////////////////////////////////////////////////////////////////////////////
+// Lookup functions
+//
+// Apple uses a number of different systems for file type information.
+// As of Spring 2010, these include:
+//
+// OS Types / OS Creators
+// File Extensions
+// Mime Types
+// Uniform Type Identifiers (UTI)
+//
+// This implementation of the type manager for Mac supports all except OS
+// Type / OS Creator codes, which have been deprecated for some time with
+// less and less support in recent versions of OS X.
+//
+// The UTI system is the internal system used by OS X, as such it offers a
+// one-to-one mapping with file types understood by Mac OS X and is the
+// easiest way to convert between type systems. However, UTI meta-data is
+// not stored with data files (as of OS X 10.6), instead the OS looks at
+// the file extension and uses this to determine the UTI. Simillarly, most
+// applications do not yet advertise the file types they can handle by UTI.
+//
+// The result is that no one typing system is suitable for all tasks. Further,
+// as there is not a one-to-one mapping between type systems for the
+// description of any given type, it follows that ambiguity cannot be precluded,
+// whichever system is taken to be the "master".
+//
+// In the implementation below I have used UTI as the master key for looking
+// up file types. Extensions and mime types are mapped to UTIs and the data
+// for each UTI contains a list of all associated extensions and mime types.
+// This has the advantage that unknown types will still be assigned a unique
+// ID, while using any other system as the master could result in conflicts
+// if there were no mime type assigned to an extension or vice versa. However
+// there is still plenty of room for ambiguity if two or more applications
+// are fighting over ownership of a particular type or group of types.
+//
+// If this proves to be serious issue it may be helpful to add some slightly
+// more cleve logic to the code so that the key used to look up a file type is
+// always first in the list in the resulting wxFileType object. I.e, if you
+// look up .mpeg3 the list you get back could be .mpeg3, mp3, .mpg3, while
+// looking up .mp3 would give .mp3, .mpg3, .mpeg3. The simplest way to do
+// this would probably to keep two separate sets of data, one for lookup
+// by extetnsion and one for lookup by mime type.
+//
+// One other point which may require consideration is handling of unrecognised
+// types. Using UTI these will be assigned a unique ID of dyn.xxx. This will
+// result in a wxFileType object being returned, although querying properties
+// on that object will fail. If it would be more helpful to return NULL in this
+// case a suitable check can be added.
+/////////////////////////////////////////////////////////////////////////////
projects / wxWidgets.git / commitdiff
