Linked by Marcus Carlson on Wed 21st Jul 2004 18:17 UTC
In these days there has been much fuzzing about the new browsing with files organizing themselves with the help of meta data. Maybe you ask yourself "What have this to do with the spatial browsing in gnome and how can it improve the browsing?". That's what I did. As I see it, the gnome people have introduced the spatial browsing so we are used to it when this new browsing is coming to town. This is very intelligent move of the gnome people and will help us adopt faster to this. This is when the spatial browsing is really making sense. I hope you see this when you've read this article.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Sorry for the double post...
If you would like to know, which files have the same content, you could find the files a.jpg und b.jpg. The same query would not be possible today without a huge overhead.
Assuming, of course, that you used only those applications that were aware of these special features in the operating system. And that you didn't need to access your data from another environment (such as over a network file system).
You would not alway be able to make the determination that files were similar. Take the example of a peer-to-peer application:
1) You start the application.
2) Somebody requests a download from you (for a.jpg).
3) The application opens a.jpg, and starts sending it.
4) You begin to download b.jpg from another user.
5) The application creates and opens b.jpg and writes the download to it.
The situation of data production and consumption in a pipe line poses similar problems.
Any scheme that doesn't have the huge overhead you mention would make mistakes, unless they relied on the applications stating specifically that b.jpg was derived from a.jpg (whoch they would have to if saving the steps along the way), and then it would be a lot of effort to modify existing applications to take advantage of it.
Addition, this would take a LOT of hard disc space. We would need to vacuum our discs to reclaim old change data instead of/as well as defragmenting, etc.
This feature could be done (in a dodgy hack manner) using the alternate streams mechanism (or whatever it is called) in NTFS. Just save the "how we got here" and "original" data in alternate streams of b.jpg.
Other problems include the case/s with multiple sources, as in a compilation of images (collage, etc)? What about temporary sources (an image off the web likely as not is copied from the browser cache, not the Internet).
This sort of scheme always sounds nice but I don't think that people will use it. As Seth describes in some of the storage documents, people don't even use directories properly, why would they use more advanced schemes?
I personally believe that search will (hopefully) start to address this. By combining an explicit query interface (like Storage) with an unintrusive implicit interface (like Dashboard) and a search system sophisticated enough to do automated clustering, and maybe a little learning, we can almost remove the neccesity for manual organisation, though I readily admit that this would suffer almost all of the things I said about your vision. Consistency is the sign of a small mind. :-)