Interoperability and Demesnes (by alaric)
Of course we can. The hard part is deciding which approach to take...
One is to press on as we are, but work hard to make better and better libraries for handling different types of files. Eventually, everyone will use the common libraries, and the differences between formats will become less important. If every image application knows JPEG, GIF, PCX, ILBM, ICO, PICT, TIFF, PNG and friends then saving an image will consist of choosing a compression setting of lossless or lossy, and JPEG and PNG files can be reported by our user interfaces as just an "image", and every app that deals with images can just register for "image" as the type of file they open, and it'll work seamlessly. But this isn't quite perfect, since there's wasted resources. Computers need to have code to read PCX and ILBM files, despite them being ancient historical relics, since they're still out there circulating about so they might turn up at any point; and so everything needs to know about them. And unless you get really careful with dynamic loading, this means that every application that reads images will end up using up virtual address space for a PCX decoder that is almost never used. The problem is that a file may contain anything, so every application needs to be prepared to deal with any eventuality.
The other approach is to establish a sanitised zone within which only a chosen set of file formats is permitted. Let's call it a demesne since that's an underused term. There is a real different between lossy and lossless images, so we might say that images are always either JPEG or PNG; better, to simplify things, we might mandate JNG or PNG, since JPEG and PNG both have their own formats for basic image data like width and height, while JNG is a wrapping of JPEG's underlying compressed image format within PNG image metadata. One might mandate that all text is in UTF-8. And so on.
This does occur, on small scales - Java software has representation of strings in memory that's based on UTF-16, and whenever a string is read from or written to the outside world, it's decoded or encoded from whatever format is out there, but all strings within the application are in UTF-16. Due to de facto standardisation, JPEG, PNG and GIF are the only image file formats that you can rely on for embedding into web pages, and GIF has been mainly superceded by PNG. Oh, and HTML for documents plus CSS for styling is also the near-mandatory standard for the Web pages themselves, although there are different versions of HTML all over the place (luckily, they're quite backwards compatible, making it fairly easy for browsers to support the union of them all in one go). The libraries for handling different file types suggested previously also create little in-memory demesnes, where there's only one representation of an image that the host application needs to worry about, with the library taking care of converting between that and all the standard file formats. We already have oceans of tiny demesnes.
But it could go further. Imagine if the entire system was a demesne. Applications could rely on a file of type "image" either being JNG or PNG, and only need to handle those two cases. How would this system interoperate with others? There would have to be a translation interface where the system touches the rest of the world - the implementations of MIME for email and web browsing on this platform would need to know about all the image formats out there, and automatically convert them to JNG or PNG upon receipt. And when sending images out, those JNGs would need to be re-wrapped to make them into JPEGs (although the PNGs would be just fine). Likewise, when a CD-ROM, DVD-ROM, USB disk, etc was inserted, there would need to be transparent conversion done.
All the software to deal with different file formats would still be needed, but at least it'd all be in one central suite of converters, shared by the storage and communication interfaces. The result would be greater efficiency, since unless the computer was involved in the business of communication it wouldn't need to be using resources for potentially decoding a PCX image. The demesne boundary could be on a different computer entirely, such as a proxy server, in which case the computer might not even need the converter suite installed at all. Within the demesne, interoperability would be seamless and guaranteed. Files of unknown types would be detected at the demesne border and the sender informed instantly, rather than a useless file working its way deep into the system before its unintelligibility became apparent.
Now, this is only really practical when setting up a system from scratch. Applications would be written to interoperate with a demesne's standard suite of formats, and then they'd only work properly in demesnes using the same suite. This would need to be standardised, with the risk of differeing demesne standards developing, for you can be sure that Apple, Microsoft, and the open source community would be unlikely to all settle for the same suite...
But when writing a complex document management system, it's quite possible to make it as a demesne. Convert incoming files to standard formats, then the indexing, viewing, editing, and processing modules become a lot simpler to implement. When designing the image manager for GoNumber.com, I made it a demesne; you can import images in any format ImageMagick can convert to PNG, then they're stored as a native-resolution PNG in the filesystem. When a JPEG of a specific resolution is required for rendering to a browser, it's generated on the fly (with a cache). When the user performs image editing operations such as cropping, scaling, and colour correction, the code that handles it only needs to worry about PNG.
So let a new bit of jargon be coined! When dealing with a complex system of modules that process information that might be encoded in any of a number of competing formats, consider a demesne as a possible design pattern!
Sat 10th May 2008 9:17 pm 
Subscribe