It's a classic design philosophy for separating out the data (model), viewer, and manipulator (controller) aspects of a system.
By creating a rich metadata soup for file and data, various viewers can show specific slices of it to the user for different purposes.
A spatial Finder would use the spatial metadata as a way of presenting the hierarchical ordering of the files, while another might be a duplicate of iTunes' organizational approach for just the sound files on your drive, and another a duplicate of iPhoto, etc, etc.
Each of these apps works with metadata for a specific type of file (sound, image, etc), but imagine the flexibility if this were all merged into one big pool of data that any app could access as it needs to.
Obj-C is moving us in that direction without the pain and suffering that we had with OpenDoc's use of statically bound languages. (C++, I'm looking in your direction...)
This reminds me of a post WAY long ago by a guy that claimed some inside connection at Apple and was spelling out this long term Apple strategy that REALLY looks like it is beginning to take shape.
Essentially, one of the things that came out of that was that things like iPhoto and iTunes were really just "specialized Finders".
First of all, excuse my ignorance since I am no expert in file systems. I have several thoughts on this topic and I hope somebody can enlighten me.
1. HFS API suck in their current form. The idea behind the API is not straightforward, is not transparent but is ugly. The low-level part of it can easily be used to frighten people.
2. HFS (together with HFS+) is the only FS with which Macs work reliably.
3. There are hundreds of popular apps which call HFS API directly.
Apple has to live with it, I'm afraid, for long enough. Backward compatibility is a very important thing which, considering ever-shrinking Apple's marketshare, is not what you readily get rid of and say 'Good riddance'. Unless, of course, Apple offers totally unheard-of possibilities which average users appreciate and learn how to use them in an hour.
The question is, can new metadata-driven API be added on top (or in addition, or anyhow) of HFS+ without sacrificing backward compatibility? Does metadata approach require a different file system organization (i.e. do bytes on the disk have to be located totally in a different manner)? Can existing node/extents/hierarchy/directories structures of HFS+ be adapted to hold abstract metadata?
Or, on the opposite, can a radically new metadata FS be developed in such a way as to support existing Carbon calls, at least, most of them?
After reading the pdf entitled "Improving the usability of the hierarchical file system", I guess the whole problem is visualization. It actually doesn't matter to users how the FS works. It matters how it lets you find what you need. So to do the next big thing? Apple has to write a new Finder which lets you assign arbitrary metadata to any file or folder and then elegantly lets you quickly find anything by using both the manually-assigned and computed metadata. The file system itself must naturally support metadata and be able to perform very fast searches.
Looking at Panther Finder makes me hope they have already made the first step. Live search is fast enough, though very limited.
1. Finder should let you assign an arbitrary key/value pair to any file (NSDictionary would suffice, I think )and provide a nice UI for that purpose.
2. Finder should be able to perform fast queries by any combination of attributes you can think of. No restrictions on boolean operations. Friendly UI required.
3. HFS+ should get simple, convenient and well-documented database API.
4. HFS+ should become multithreaded to perform all sorts of database access efficiently.
5. Finder's UI should be re-worked to better visualize what the user is doing. It should adapt itself to various (from very simple to very complicated) queries, let the user save queries and cache their results.
6. HFS+ driver must be able to notify any application of any change to any file/folder or their attributes in real time in order to say No to polling the FS.
And that, I should say, is no easy task to accomplish. If Apple can do it all nicely, it may change the way we use computers for a decade or two.
After reading the pdf entitled "Improving the usability of the hierarchical file system", I guess the whole problem is visualization. It actually doesn't matter to users how the FS works. It matters how it lets you find what you need.
*BINGO* HSF+ can stand exactly as it is... the user is certainly never going to use the APIs directly, and any new database-driven model is going to require new hooks... but just not at the FS level.
Quote:
So to do the next big thing? Apple has to write a new Finder which lets you assign arbitrary metadata to any file or folder and then elegantly lets you quickly find anything by using both the manually-assigned and computed metadata. The file system itself must naturally support metadata and be able to perform very fast searches.
Looking at Panther Finder makes me hope they have already made the first step. Live search is fast enough, though very limited.
Yup. Baby steps.
Quote:
1. Finder should let you assign an arbitrary key/value pair to any file (NSDictionary would suffice, I think )and provide a nice UI for that purpose.
2. Finder should be able to perform fast queries by any combination of attributes you can think of. No restrictions on boolean operations. Friendly UI required.
3. HFS+ should get simple, convenient and well-documented database API.
4. HFS+ should become multithreaded to perform all sorts of database access efficiently.
5. Finder's UI should be re-worked to better visualize what the user is doing. It should adapt itself to various (from very simple to very complicated) queries, let the user save queries and cache their results.
6. HFS+ driver must be able to notify any application of any change to any file/folder or their attributes in real time in order to say No to polling the FS.
Don't think of this in terms of 'Finder' and 'HFS+'. Those are, respectively, too high-level and too low-level to be the correct layer to implement this. Instead, replace those terms with 'MetadataServices' in all but the UI decisions (1b, 2b and 5). Existing apps continue to call HFS+ directly if they choose to (but they really shouldn't in the first place for all but a small handful of utility apps), new apps use the MetadataServices if they want to access it from that level. Everybody wins.
Quote:
And that, I should say, is no easy task to accomplish. If Apple can do it all nicely, it may change the way we use computers for a decade or two.
Comments
It's a classic design philosophy for separating out the data (model), viewer, and manipulator (controller) aspects of a system.
By creating a rich metadata soup for file and data, various viewers can show specific slices of it to the user for different purposes.
A spatial Finder would use the spatial metadata as a way of presenting the hierarchical ordering of the files, while another might be a duplicate of iTunes' organizational approach for just the sound files on your drive, and another a duplicate of iPhoto, etc, etc.
Each of these apps works with metadata for a specific type of file (sound, image, etc), but imagine the flexibility if this were all merged into one big pool of data that any app could access as it needs to.
It'd be like... like...
Newton.
Welcome to 1995.
Obj-C is moving us in that direction without the pain and suffering that we had with OpenDoc's use of statically bound languages. (C++, I'm looking in your direction...)
We're getting there.
Originally posted by Chris Cuilla
This reminds me of a post WAY long ago by a guy that claimed some inside connection at Apple and was spelling out this long term Apple strategy that REALLY looks like it is beginning to take shape.
Essentially, one of the things that came out of that was that things like iPhoto and iTunes were really just "specialized Finders".
Do you mean these MacNN threads?
Rethinking Interface
Rethinking Interface: Jaguar and beyond
1. HFS API suck in their current form. The idea behind the API is not straightforward, is not transparent but is ugly. The low-level part of it can easily be used to frighten people.
2. HFS (together with HFS+) is the only FS with which Macs work reliably.
3. There are hundreds of popular apps which call HFS API directly.
Apple has to live with it, I'm afraid, for long enough. Backward compatibility is a very important thing which, considering ever-shrinking Apple's marketshare, is not what you readily get rid of and say 'Good riddance'. Unless, of course, Apple offers totally unheard-of possibilities which average users appreciate and learn how to use them in an hour.
The question is, can new metadata-driven API be added on top (or in addition, or anyhow) of HFS+ without sacrificing backward compatibility? Does metadata approach require a different file system organization (i.e. do bytes on the disk have to be located totally in a different manner)? Can existing node/extents/hierarchy/directories structures of HFS+ be adapted to hold abstract metadata?
Or, on the opposite, can a radically new metadata FS be developed in such a way as to support existing Carbon calls, at least, most of them?
Thanks.
Looking at Panther Finder makes me hope they have already made the first step. Live search is fast enough, though very limited.
1. Finder should let you assign an arbitrary key/value pair to any file (NSDictionary would suffice, I think
2. Finder should be able to perform fast queries by any combination of attributes you can think of. No restrictions on boolean operations. Friendly UI required.
3. HFS+ should get simple, convenient and well-documented database API.
4. HFS+ should become multithreaded to perform all sorts of database access efficiently.
5. Finder's UI should be re-worked to better visualize what the user is doing. It should adapt itself to various (from very simple to very complicated) queries, let the user save queries and cache their results.
6. HFS+ driver must be able to notify any application of any change to any file/folder or their attributes in real time in order to say No to polling the FS.
And that, I should say, is no easy task to accomplish. If Apple can do it all nicely, it may change the way we use computers for a decade or two.
Originally posted by murk
Do you mean these MacNN threads?
Rethinking Interface
Rethinking Interface: Jaguar and beyond
Not those, but those sure do look like someone that knows what they were talking about in regards to where Apple was/is going.
Originally posted by costique
After reading the pdf entitled "Improving the usability of the hierarchical file system", I guess the whole problem is visualization. It actually doesn't matter to users how the FS works. It matters how it lets you find what you need.
*BINGO* HSF+ can stand exactly as it is... the user is certainly never going to use the APIs directly, and any new database-driven model is going to require new hooks... but just not at the FS level.
So to do the next big thing? Apple has to write a new Finder which lets you assign arbitrary metadata to any file or folder and then elegantly lets you quickly find anything by using both the manually-assigned and computed metadata. The file system itself must naturally support metadata and be able to perform very fast searches.
Looking at Panther Finder makes me hope they have already made the first step. Live search is fast enough, though very limited.
Yup. Baby steps.
1. Finder should let you assign an arbitrary key/value pair to any file (NSDictionary would suffice, I think
2. Finder should be able to perform fast queries by any combination of attributes you can think of. No restrictions on boolean operations. Friendly UI required.
3. HFS+ should get simple, convenient and well-documented database API.
4. HFS+ should become multithreaded to perform all sorts of database access efficiently.
5. Finder's UI should be re-worked to better visualize what the user is doing. It should adapt itself to various (from very simple to very complicated) queries, let the user save queries and cache their results.
6. HFS+ driver must be able to notify any application of any change to any file/folder or their attributes in real time in order to say No to polling the FS.
Don't think of this in terms of 'Finder' and 'HFS+'. Those are, respectively, too high-level and too low-level to be the correct layer to implement this. Instead, replace those terms with 'MetadataServices' in all but the UI decisions (1b, 2b and 5). Existing apps continue to call HFS+ directly if they choose to (but they really shouldn't in the first place for all but a small handful of utility apps), new apps use the MetadataServices if they want to access it from that level. Everybody wins.
And that, I should say, is no easy task to accomplish. If Apple can do it all nicely, it may change the way we use computers for a decade or two.
I think they can, and yes, it will.