Apps as containers (by alaric)
As I have mentioned before, it annoys me that many applications try (subtly or otherwise) to appear as the 'containers' of your data; they are both editors of a particular type of object, and a browsing/management interface for that type of object. The insidiously widespread case being applications that have 'Open' and 'Save As' menu items that pop up mini filesystem browsers, only showing the types of documents that application cares about and hiding others.
On my Mac, lots of apps do this even more blatantly. Mail.app is hardly unusual as mail programs go in that it has its own trees of folders, but it still annoys me that it's so when there's a perfectly good filesystem. iTunes has its special four-pane browser; sure, it's a nice browser for music files, but it'd be nicer if the filesystem browser could do that for anything - perhaps list my documents by category, project, and date - and iTunes just be a music player. And, of course, there's a tree of bookmarks in every web browser. And so on.
Quicksilver is nice - it's a tool for Macs that uses a set of plugins to extract the 'contents' of all supported applications, plus the filesystem itself, and build up a unified index. It lets you find objects quickly in that index with partial matching, and with the ability for objects that contain other objects to be browsed, as long as the parent object is in the index. Once you've found an object, then the plugins provide a suite of appropriate actions to be performed on that object. So the iTunes plugin gives you a "Browse Albums" object you can get to by typing "brow alb", then hit right arrow to see a list of albums (extracted directly from iTunes on the fly), use partial matching to find an album, then hit right arrow to see a track listing, select a track, and then have commands such as "Play", "Add to end of Party Shuffle", "Reveal" (opens up the Finder on the actual MP3 file), etc.
This is nice, since it brings together all the different models in different apps into a single interface that I can then examine in various ways. Powerful network effects arise due to this commonality.
Ideally, it'd be built into OS X and all apps would expose Quicksilver catalogues in much the same way they currently expose AppleScript vocabularies...
But, of course, I look at this and I think: what of ARGON? I don't normally think much about user interfacing with ARGON, mainly because I think it'll be a very long time before it's worth really investing the time in building an ARGON GUI; it has much more of a market in the realm of servers and embedded systems for now, since the desktop market is dominated by Microsoft, Apple, and Unix, with a huge inertia of existing applications behind all three.
But, still, it's fun to think about user interfacing issues, and I'd rather make sure I'm laying good foundations for an eventual UI from the ground up than end up with a badly developed hack if I ever do develop the UI side of things.
Part of the problem with current applications, I think, is that if they store their stuff in the filesystem, they are at the mercy of said filesystem. A mail client could just store messages as individual files in the filesystem, with a background job that fetches new mail from a server and creates matching files. But then it's at the mercy of the operating system's file browser to present a decent interface to that. It has no way of controlling this. Also, if you're talking to an IMAP server, then there's no way for the mail client to know if you drag a message between two folders. Well, some OSes let applications listen for notifications of filesystem events; but even then you can't usually step in and prevent an illegal move from happening if the backend server you're talking to wouldn't allow it.
Some OSes let you mount as a 'virtual filesystem', and create a folder that's not backed on disk, full of virtual files that are created on the fly by the application. All filesystem actions - opens, creates, moves, renames, etc - are handled by sending requests to the application, which may reject them, or handle it however it sees fit. That's more like it. However, it can be slow; all access to that subtree involves inter-process communication with the application.
So what I've done in ARGON is to define the way the 'browsable directory tree' works in terms of entities. Each entity, via CARBON, may claim to be a container entity and expose a list of child entities, along with information about them. This information includes potentially quite detailled display hints. Since it's CARBON, it's extensible and flexible.
But the neat thing about CARBON is how it supports blending static and dynamic data. Every entity may provide static CARBON information, which the OS stores on its behalf, in TUNGSTEN. CARBON may then provide rapid access to this, by direct reference to TUNGSTEN, without invoking application code. It can be as fast as a static filesystem.
However, partial statements may be placed in the static data that reference application code. When those statements are requested, the application is actually invoked, and fills in the answers. Also, the static data may be treated as a cache, and given expiry timeouts.
So an IMAP interface entity might contact the IMAP server and populate itself with static CARBON data claiming the existance of a tree of virtual entities representing your mail folders, with email messages as entities, and attachments as child entities of them, and so on. However, it may also attach a note saying that the data would need checking after a minute. This is different to scheduling a request to refresh it every minute; it merely means that if the data is queried, but more than a minute has passed since the last refresh, the application is invoked and asked to do a general refresh. In the case of IMAP it would probably request lazy refreshing, in which case the request is still satiated with the old data while the refresh is in progress; with strict refreshing, after a minute, requests would block until the application had finished updating.
And for large objects like attachments, rather than downloading them from the server and storing them in the static state, it could just leave partial statements about their contents. If that information is requested, the application is invoked, and fetches the attachment. It can then replace the partial statement with a static statement containing the downloaded data, and return that to the client.
The end result, I hope, is that a single unified CARBON convention for things-within-things can be used wherever that structure arises. And, therefore, the positive effects of unified access to information based on that basic fundamental structure can be easily enjoyed...
Mon 5th Nov 2007 1:29 am 
Subscribe
By Peter, Mon 5th Nov 2007 @ 8:56 am
You should have a look at Haiku. They store everything in the filesystem. I saw a presentation at this year's T-DOSE and they showed how the instant messaging application stored contact data for all your contacts in metadata of files, one file per contact. The mail application uses this information as well, and you can also search contacts with the filesystem browser, simply by filtering on particular metadata fields.
I was really impressed by it, even if the OS is not "production-ready" yet. Unfortunately, I couldn't really get started with it because qemu is simply too damn slow on my Mac and it does not run natively on PPC. 🙁