Linked by Thom Holwerda on Wed 25th Jul 2012 22:18 UTC
OSNews, Generic OSes The article I'm about to link to, by Oliver Reichenstein, is pretty terrible, but it's a good way for me to bring up something I've been meaning to talk about. First, the article: "Apple has been working on its file system and with iOS it had almost killed the concept of folders - before reintroducing them with a peculiar restriction: only one level! With Mountain Lion it brings its one folder level logic to OSX. What could be the reason for such a restrictive measure?" So, where does this crusade against directory structures (not file systems, as the article aggravatingly keeps stating) come from?
Permalink for comment 528462
To read all comments associated with this story, please click here.
Member since:

""Don't get me wrong: organising data hierarchically is a mighty fine tool for certain types of problems (e.g. it makes a lot of sense for stuff like OS and application files), but for user data it is an absolute tyranny."

I still have to disagree with you here though, even once we've expelled the disk-saved/memory-loaded duality, which was invented for the computer's sake so to speak, it hasn't eliminated clutter nor the user's desire to keep certain documents organised in relative hierarchies, metadata only takes you so far and works much better in some cases than others.

I see no reason why parent-child and sibling relationships couldn't be expressed via metadata as well. Point is, users should neither be constrained by it nor forced to maintain it themselves. Heck, from a user's POV a file path is just degenerate metadata, e.g. /usr/local/bin/foo tells me that 'foo' is an executable tool that I installed myself. By its own nature a file path also implies that certain hierarchical relationships exist, but whether these are unique, optimal, helpful, necessary or even appropriate isn't something that can be answered without a lot more expert insight. Insight that the system should automatically provide as much as possible so the user (who has better things to do with their life) doesn't have to work at it themselves.

Once properly decoupled, users and applications can express and view whatever shaped graph(s) they like; they're all equal in the display system's eye. And it can be left to self-organise by default, according to whatever criteria the storage system deems most appropriate to a given data type; any additional organisational advice that a user might wish to contribute are merely icing on top.

It works better once you start thinking about how to decompose application functionality as well. Consider an email client, which consists of a functional core that knows how to talk POP/IMAP/SMTP, a big old data silo (which may be local, remote, or spread over both), and a bit of user interface for interacting with the both of them. Recast this though, and the core component stays the same, while the data store and UI become parts of an expert system for providing one 'intelligent' view onto a specific type of user data - essentially just one more plugin extension to the general-purpose data storage system you already have. You eliminate the closed-off data silo, along with all the dog-work needed to implement its foundation, benefiting both users - who have much freer access to their data - and developers - who can leverage far more shared architecture, leaving them much more time to invent other cool toys, go down the pub, etc.

""Good luck with effecting any sort of change though. There are all too many folks who'll fight to the death to maintain a nasty, ugly, crippled status-quo where they are the undisputed kings than sweep it away to stand shoulder-to-shoulder all the little folk in a brave new world."

I certainly hope you are not referring to me, because I agree with you. The status-quo really does impede progress sometimes.

Don't worry; they shall be known by their actions, not by mere words. Folks who really want to effect change will put their backs into it. Folks who stand to lose power and status and are unwilling to accept that will battle against it. While the majority will just bring popcorn, of course. ;)

I don't feel user directories do that since they're entirely optional and don't interfere with metadata.

A one-armed straitjacket is still a straitjacket; you've just gotten so used to living with it that it's never occurred you could take it off at any time. ;)

Treating one particular idiom/organisation/representation as a special case that is hard-wired into the storage system requires a duplication of effort, and will colour and constrain everything else that the system might want to do. Whereas if you treat your much loved tree structures as soft or 'virtual' relationships, you can express them just as easily within your general metadata-driven framework without imposing any of those disadvantages.

Meanwhile, since the system now has unimpeded control over how and where everything is physically stored, it can make whatever rule-driven arrangements it deems best: e.g. an application (executable plus various resources) may be written out locally as an old-school file system hierarchy for efficient performance; your favourite Rush tracks are replicated across your local devices for easy access; the hilarious cat pictures you just took yourself are replicated to your online personal cloud space for safe-keeping and perhaps from there onto your favourite public sharing sites as well; etc. While your 'smart viewers' can display that info from anywhere, to anywhere, in whatever way(s) you like.

Reply Parent Score: 3