I mentioned in my previous post that I was thinking about user-mode filesystems as a way to write runtime- and language-independent APIs. Well, I've deciided I don't like the idea.
The single word that killed it was this: discoverability.
An API implemented as a file system would be difficult to "discover", even if you knew those files were provided dynamically by software. Here's what I mean.
1. It wouldn't be very self-documenting.
It would be difficult to learn about the API without seeing the documentation. A good API should be possible to learn and use (at least, at a basic level) without any formal help. And it always helps if the API conforms to some industry "norm" of organization. Config files and input/output redirection are very common in some operating systems. But manipulating files and folders that map to database records or domain objects is an unheard-of concept, and any pattern of mapping would be necessarily home-grown.
2. It would be hard to find the providing code.
Part of the point of user-mode file systems is that they're indistinguishable from the "regular" file system. It's hard enough to tell where one ends and the other begins. Finding out what software is "providing" which branch(es) of the folder hierarchy could be very difficult, especially if the user doing the research doesn't have administrative access to the server.
3. (I can't think of a good third point here, which I feel would strengthen the post. But I'm sure that as soon as I click "Publish Post", I'll think of a good one. So this is just a placeholder until then.)
User-mode file systems tempted me with the ability to write an API that didn't involve a wordy protocol (like web services) or have the limitations of data-level access. But I realize that currently accepted API mechanisms (especially web services) offer benefits that overcome their drawbacks. File system APIs will need to mature with a good set of best practices before I can accept them for my use.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment