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?
Thread beginning with comment 528447
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

hhas,

Thank you for that insightful post. I agree with your ideas. I've given the same thoughts to the duality of documents on storage and documents on display. That duality isn't inherent, it was evolutionary just like you said. I think there are some platforms that tried to treat all documents as active documents and eliminate the notion of opening & saving them. It's unfortunately such projects have been relegated to obscure niche usage since I think it's a nice alternative.


"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.

People used hierarchies even before computers came on the scene because it was a natural approach for them to organise data - it's not like they were invented for the computer's own sake. They exist in all kinds of "human" contexts; my favourite computer part supplier, newegg, organises their website products in a hierarchy. That wasn't for the benefit of their web server, or their developers. No, it was for my benefit as a user. In addition to hierarchies, they also provide great metadata searching too, proving that both approaches are complementary. We should my own computer not permit me to work this way if I want to?

"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. OSS/*nix folks should be taking the lead in shaping the future to everyone's best interests."

I certainly hope you are not referring to me, because I agree with you. The status-quo really does impede progress sometimes. I don't feel user directories do that since they're entirely optional and don't interfere with metadata.

Reply Parent Score: 2

hhas Member since:
2006-11-28

""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

Alfman Member since:
2011-01-28

hhas,

You've got some great ideas.

"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."


I didn't mean to imply that a directory structure cannot be considered a kind of metadata. I'd point out that even today, even though we think of directories as being special, it really IS metadata for the file (which is represented as inode inside the linux kernel, and not by the filename metadata), it just happens to be the only indexed metadata available to us in *nix. That's what's restrictive. We don't need to get rid of the directory metadata, we just need to add more indexed metadata types. "Directory" metadata would be optional, like other metadata types. It should not be treated specially. As long as it's available, that's what's important.


"Once properly decoupled, users and applications can express and view whatever shaped graph(s) they like"

I'm not sure if using a full graph instead of a tree would be more confusing for users. It might break alot of recursive directory operations that are possible now. For example, deleting a directory and it's children could be extremely dangerous. However I'm not opposed to the idea and I'd like to see it implemented.


"It works better once you start thinking about how to decompose application functionality as well"

I've often wished we had a way to treat all data the same regardless of what it was. Emails shouldn't be managed under a separate room or filing system than any of my other documents. If I want to create a directory (you probably despise that terminology, can we substitute "container"?) to hold a specific set of emails and other documents, I should be able to - nothing is special about the email. I might even like to do the same thing on a more fine grained approach, using the filing system for email addresses & contacts.

All applications on such a platform should use the standard data types so contacts don't have to be "synchronized", they'd simply be shared.


I think I'm loving it ;)


"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."

It's not a straitjacket though because it's optional. Having a hammer doesn't mean I always have to use it. Just because a hammer can't do everything doesn't mean it's not worth having.

"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."

I never really wanted it to be special, I wanted the concept of hierarchies to be integrated along with other forms of metadata. There's no reason the computer should not be able to arrange things in hierarchies when that's what the user explicitly wants to do, which is what I've been trying to point out since my first post.


"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:"

I agree with the idea, however the "problem" was never with directories in the first place, it is the implementation of them. AFS is a great example of a file system that transparently handles local/remote storage without regards to a file's path. I agree very strongly that a filing system's organization should not drive (or be driven by) it's storage requirements.

Reply Parent Score: 2