Weakened Interface

This is a UserInterface AntiPattern.

The program performs some kind of operation on objects then presents the user with fewer operations on the resulting objects than they had on the original objects to begin with.

Most P2P filesharing programs have this pattern. Kazaa, soulseek, eDonkey, they all have inferior interfaces. Only Bittorrent recognizes the limitations of such junk interfaces by not offering any interface.

So here's how it works. In those programs, what you have access to are concrete files and directories. Often, highly organized files and directories. The facility which these programs provide is the searching and downloading of files and directories by their names. eDonkey provides additional facilities; aggregating files by their hash values.

Now here's the problem. Once you've found what you want and put it in the download queue, the interface you have to these objects is downright miserable. You may have more than 200 files in your download queue, but you can't organize them in any way. You might have 10 different versions of a song in your download queue, but you can't search the queue by name to find them when one of them's succeeded downloading! That's because your download queue isn't a directory like all the other directories which the program imports; it's a deliberately weakened object instead. The same goes for the file objects in your download queue, they too are specially weakened.

So what's the right way to design an interface? It's to not provide one in the first place but rather to extend the existing interface. It's to produce NoApplication.

Bittorrent extends the interface of the typical filesystem by providing downloader objects called torrents that provide the single facility of downloading an object from remote users. These torrents can be operated on by the existing facilities in the filesystem, including but not limited to renaming, organizing and searching.

And if there were queue directories whose job it was to run torrents (or any other executable type) one after the other then this scheme would be downright perfect.

This, by the way, is EmbedVsExtend all over again, and the right answer is to extend, not to embed.

If more programs subscribe to this idea, the interfaces for querying and manipulating file systems will have to improve. For example, current file systems (ones that I know of, anyway) don't understand the concept of a file being partially complete. If a file is being downloaded by Bittorrent, the file system interface only says how large it is at the moment. It should say how large it will be, how fast it's being finished, and so on. I can't wait until the idiotic download managers in web browsers can gracefully disappear.

It's true that filesystems have to be replaced by something vastly more powerful, general and sophisticated. Something that's actually secure, allows for multiple logical containment (multiple parent links), bidirectional links, different types of links, and many other things. It never occurred to me before but I have to say that embedding an understanding of an expanding object into the filesystem is a bad idea. (For a while it looked like a great idea.)

There are lots of concepts you can embed into a filesystem. One of them's copy. You can even do so securely if your filesystem is secure. Unfortunately, if your system of filesystems includes networking, then you end up with the possibility that an user asks a copy over the network. Now, that's a pretty neat thing to do, but it opens up questions about how much your copy operation should care about atomicity, how often it should retry, et cetera. And those aren't questions I'm interested in answering. Far better to provide a general facility to aggregate operations into atomic transactions.

There's more. Suppose you did include a "this object is meant to be X kilobytes" attribute into your objects. You could do that. After all, you already have a "size" attribute. Hell, you could even have a "this object is meant to be a movie once it's complete" attribute. Unfortunately, "meant to be" is a pretty fuzzy concept to build into the filesystem. Especially when you don't need to.

Because the proper place for all these concepts isn't in the object store (a souped up filesystem) but the object manager (a souped up window manager). The object manager deals with objects' classes, automatically calling the appropriate viewer for a particular class of object. So when the object manager runs across a .torrent object, it brings up the torrent viewer which tells the user how big the object is meant to be, how fast it's downloading, et cetera. And that's as it should be.

But there's more. In a non-broken object store, the .torrent (an object) has a link to the intended destination of whatever it's downloading (just like a directory). So when it's finished downloading, it moves the object to its intended destination where it can be seen directly then it changes its link to the object it moved over. That way, by going inside the torrent (using the generic object viewer instead of the torrent viewer) you can see the link to the complete object. And by doing the same to the movie (or whatever) you can see a link back to the torrent.

I agree. I was talking about the "file system interface", or object manager as you call it, but I accidentally made it sound as if I wanted the file system itself to know about partial completion. I could refactor this discussion into document mode, but I have a feeling you'd do it better. :)