On Sep 22, 2011, at 15:48 , Charles Srstka wrote: > The idea of UTI is that you just want to handle a certain type of file; you > don’t care *how* the OS figures out that it’s that particular type of file. > If someone comes up with a newer and better way to implement file types in > the future, the UTI system will just be updated to handle that new type > system and your app will continue to work with no modifications. That, along > with the hierarchy, is what is nice about UTI.
I believe you are overlooking two points, one minor and one major: 1. The minor point is that *if* the "UTI system" can never change -- I mean, if there's never going to be a new or enhanced UTI system, independently of your imagined new type system -- then there really isn't any value in using what you call a "type system". You may as well store the UTI. If the UTI system can potentially change in the future, I agree there's a small benefit to the abstraction. A change in the UTI system would potentially require some changes to applications. A change to the type system would potentially require changes to the file system. It's useful to separate the kinds of changes. 2. The major point is that there is, historically and currently, no commonality at all in metadata capabilities across file systems (especially across platforms) *except* for the filename and/or the file extension. That is, there's no place to store a file type transparently across file systems *except* within the filename/extension combination, and that place is unfortunately user-visible, so it needs to be fairly short and simple. (Not to mention that it's also accessible to the user and can easily be arbitrarily changed. But that's a different problem.) Apple *tried* to solve this problem in Mac OS (the original one, not Mac OS X) with file and creator types. The result was that Apple was laughed out of court, and was saddled with the perception of Mac files being incompatible and un-interchangeable. (This was made worse with file forks, but in that case Win NT also adopted the forked file architecture. Still, that whole thing went nowhere in the industry and user sensibility generally.) Apple persisted with file/creator types for years, but finally gave up in Mac OS X. Since then, there has never been a breath of a suggestion that Apple would ever go back to a situation where files would be allowed to be un-interchangeable due to file system differences. We are stuck with the lowest common denominator of *all* mainstream Mac/Windows/Unix file systems for the foreseeable future. Thus, it is not really the case that the UTI/extension distinction serves us as a useful abstraction. Rather, we're stuck with extensions as the *only* practical platform-agnostic metadata storage, in spite of the fact that extensions are really, really lousy for pretty much all of the purposes for which they're intended. And all of that sucks for the attractiveness of adopting UTIs. Regardless of any minor abstractive advantages. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
