[quote]With proper meta-data support, ala BeOS, smart playlists are nothing new, in fact you can have them right now inthe Finder equivalent of the BeOS.<hr></blockquote>
It would be nice, though, to have some preset queries. Also, the Finder should, via plugins, support various file formats' internal metadata. Adobe isn't going to change, for instance, the Photoshop file format just because the Mac supports filesystem-leve metadata, but the Finder could still get the size and resolution of an image.
That stuff comes right along with proper meta-data support in the OS... For instance, there are plug-ins for BeOS that will make proper attributes for MP3 files from the ID3 tags of those files. Such a utility exists for OSX, but can only, obviously, change the file name from the ID3 tags.
The kind of stuff we're seeing in Jaguar, specific file information shown directly in the Finder under the files (such as folder contents, audio length etc.) is giving me hope that we might in the near future see a new FS and everything that goes with it.
Here is some info that was posted a while ago regarding the post-Jag release, on April 7th, on the MacNN forums, ie before the WWDC presentation, and all the leaks that followed. At that time, only 6B11 had leaked. And this source nailed the Mail.app spam filtering feature.
[quote]*\tAbility to define unlimited additional Finder labels (ties in with DB filesystem featuers -- more on this below).
*\tiTunes-style searching of the file system using a "browse" mode. Searching is done based on file-metadata stored in an extended HFS+ spec (backwards compatible, more on this later) in an effort to copy and improve upon the DB-like aspects of the BeOS filesystem.
*\tNew GUI element for browsing file system: the "pile". This extends the file/folder metaphor by allowing the user to group documents in piles which are represented on screen as a stack of docs, each one slightly rotated so you can see the edges of the one underneath it. Anti-aliased Quartz proving really handy for this.
*\tHFS+ to support softupdates (similar to FreeBSD softupdates) which provide journalling filesystem like capabilities (ie. quick crash recovery) without actually being a journalling filesystem. These extensions are backwards compatibile with today's HFS+ in the same way that ext2/ext3 are interchangeable on Linux.
<hr></blockquote>
I really don't know what to make of this, since the author retracted his post a couple of hours afterwards... But it does provide for interesting speculation. The next update will be Leopard, according to him.
Piles at least were a Copeland idea. Tog still brings up the idea every now and then. I can see it now, just like the Inkwell comment: "You would think that a few hundred million dollars in Copleand devlopment would get us something."
This is a really great thread, and I hope Apple is viewing it. The concepts debated here, if properly implemented in the Finder, would go a long way to moving us forward from 1984. I hope Apple devises a new scheme synthesized from incipient Copland work as well as the BeOS. It seems that Apple is moving in that direction with iTunes 3, but I'm worried the focus maybe too narrow. While Apple was working on getting making iTunes 3 smarter, it left OS X as a whole dumber. We're still using file extensions as the preferred native method, rather than what it should be relegated to - a tool of last resort. I'm hoping the other posters are right, that Apple is far thinking and will deliver when the time is right.
I think Apple has been in the process of clearing the deck with regard to metadata. The inclusion of file extensions is simply a necessary "evil," a first step. I'm pretty convinced they have something else up their sleeves instead of labels, file and data forks.
Agreed. Everyone seems to want everything, and now. While I totally understand that feeling, you have to stop and realize that the absolute hardest part of software development, bar none, is getting the foundational concepts correct.
If those are off, nothing else works as well as it should.
If those are well done, almost anything can be accomplished, and easily.
What happens, of course, is that external viewers (customers, clueless management, clueless engineers) see 'no progress being made', get impatient, and force the schedule when the underlying system isn't really ready... and then you get a big hack, with features tacked on the outside willy-nilly instead of a nice clean system. This leads to future maintenance nightmares, and having to scrap the system on a semi-regular basis just to add that last killer feature that everyone's clamoring for.
<strong>I think Apple has been in the process of clearing the deck with regard to metadata. The inclusion of file extensions is simply a necessary "evil," a first step. I'm pretty convinced they have something else up their sleeves instead of labels, file and data forks.</strong><hr></blockquote>
Comments
It would be nice, though, to have some preset queries. Also, the Finder should, via plugins, support various file formats' internal metadata. Adobe isn't going to change, for instance, the Photoshop file format just because the Mac supports filesystem-leve metadata, but the Finder could still get the size and resolution of an image.
The kind of stuff we're seeing in Jaguar, specific file information shown directly in the Finder under the files (such as folder contents, audio length etc.) is giving me hope that we might in the near future see a new FS and everything that goes with it.
Here is some info that was posted a while ago regarding the post-Jag release, on April 7th, on the MacNN forums, ie before the WWDC presentation, and all the leaks that followed. At that time, only 6B11 had leaked. And this source nailed the Mail.app spam filtering feature.
[quote]*\tAbility to define unlimited additional Finder labels (ties in with DB filesystem featuers -- more on this below).
*\tiTunes-style searching of the file system using a "browse" mode. Searching is done based on file-metadata stored in an extended HFS+ spec (backwards compatible, more on this later) in an effort to copy and improve upon the DB-like aspects of the BeOS filesystem.
*\tNew GUI element for browsing file system: the "pile". This extends the file/folder metaphor by allowing the user to group documents in piles which are represented on screen as a stack of docs, each one slightly rotated so you can see the edges of the one underneath it. Anti-aliased Quartz proving really handy for this.
*\tHFS+ to support softupdates (similar to FreeBSD softupdates) which provide journalling filesystem like capabilities (ie. quick crash recovery) without actually being a journalling filesystem. These extensions are backwards compatibile with today's HFS+ in the same way that ext2/ext3 are interchangeable on Linux.
<hr></blockquote>
I really don't know what to make of this, since the author retracted his post a couple of hours afterwards... But it does provide for interesting speculation. The next update will be Leopard, according to him.
[ 07-26-2002: Message edited by: SYN ]</p>
If those are off, nothing else works as well as it should.
If those are well done, almost anything can be accomplished, and easily.
What happens, of course, is that external viewers (customers, clueless management, clueless engineers) see 'no progress being made', get impatient, and force the schedule when the underlying system isn't really ready... and then you get a big hack, with features tacked on the outside willy-nilly instead of a nice clean system. This leads to future maintenance nightmares, and having to scrap the system on a semi-regular basis just to add that last killer feature that everyone's clamoring for.
I'm happy to wait the little bit more.
<strong>I wonder what the guy who authored BeOS's file system is working on? Remember Apple hired him several months ago.
Hmm.... I wonder....
<strong>I think Apple has been in the process of clearing the deck with regard to metadata. The inclusion of file extensions is simply a necessary "evil," a first step. I'm pretty convinced they have something else up their sleeves instead of labels, file and data forks.</strong><hr></blockquote>
I tend to agree.