cascading filetype demultiplexing on windows

Yesterday, Leon (aka secretGeek) came up with the cool idea of ‘cascading filetypes‘. (go read that now or the rest of this will make no sense at all)

Update 2006-07-8 : proof of concept implementation

Leon’s original proposal was to have the final extension be unique to each application, e.g.


The problem here is that this would require Microsoft to modify the Windows shell to understand the heirarchy of file types. This is a classic bootstrapping ‘chicken and egg‘ problem – there’s no incentive to modify the shell unless there are apps that would use the functionality, but the apps can’t get built unless the shell is already modified.

But a slight tweak would turn this into something that could be incrementally deployed, namely using a standard extension that pointed at an app the did nothing but parse the file name, walk the heirarchy of file types, and then look in the registry for the appropriate file to execute.

I propose that the file extension that is used be ‘CFD’, partly because ‘Cascading Filetype Demultiplexing’ sounds kinda cool, and also because not much else seems to be associated with that extension.

Also, even though XML strictly speaking is SGML, I don’t think there will be anyone out there who has an editor associated with SGML but not with XML, I’d suggest dropping that from the name as well.

So the example above would change to:

So to get this idea to float, this is what needs to happen:

First, there needs to be a freely distributable app that can bind to ".cfd". Actually there can be a whole bunch of implementations of apps that claim that extension, as long as they all follow the same convention of parsing the filename to find the appropriate app to hand off to,

Then developers wanting the advantage of cascading filetypes (namely, being able to bind a doc to your own app for some verbs, such as ‘open’, and have the shell hand off to another app for other verbs, such as ‘edit’) need to do the following:

  1. make up a new extension unique to your application (as in .snapper, from Leon’s example) 
  2. during your application install, you need to register your unique extension with the shell, and tell it what DDE verbs you implement (e.g. ‘open’)
  3. your install should ALSO make sure that a cascading filetype demultiplixer is installed (i.e. that something is registered with the shell for the .cfd extension). If nothing is associated with that extension, then you should also install the cascading filetype demultiplexer.
  4. when your app creates files, make sure the filenames following the cascading filetype extension, with your unique extension and then ".cfd" at the end.

If this idea takes off,  and apps start using this, then maybe MS can build the demultiplexing directly into the shell, in which case the need to install the separate demultiplexing app goes away.

Anyone wanting to start implementing a demultiplexer should probably start by reading this MSDN article on Verbs and File Associations

This entry was posted in Uncategorized. Bookmark the permalink.

Comments are closed.