On Sep 22, 2011, at 6:59 PM, Quincey Morris wrote: > 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.
Sure there can be a “new or enhanced” UTI system, as long as its (rather simple) interfaces continue to work with current applications. Since the behind-the-scenes of how the UTI system detects what types of files is abstracted away, it can be changed at any time with no ill effects. Relying on just storing the UTI would not work on all filesystems, as you point out below, and would just cause all the old problems we had with type/creator codes on the classic Mac OS all over again. > 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. Not necessarily. The lesson learned from that situation was that Apple can’t go out and solve this kind of problem all on its own. If they go out and work together with the other vendors, the situation could change. If I’m correctly informed, WinFS was going to be capable of storing file types, and assuming Microsoft ever does get something like this working, Apple and MS could work out a cross-platform standard. Even assuming the status quo of flat files + extensions stays forever, though, there are still things you can do with UTIs. The most obvious is to analyze the file’s contents to determine what type of file it is. There are plenty of file types out there that can be identified by examining the first few bytes of the file — it would not be very difficult to augment the UTI system to take those into account when determining the type of a file, and as SSDs become more prevalent, the performance penalty for doing so will decrease significantly. The UTI system could also take into account certain naming conventions — like the README, Makefile, and other similar files that often come with source code distributions but contain no way for the current type system to correctly identify them as text files. The UTI system could present them as public.text to applications, and they would just open with no hassles. Abstracting the type system away opens the door for applying any amount of smarts to type identification without applications needing to be aware of it. Charles_______________________________________________ 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
