Interoperability and Demesnes (by alaric)
There are two main kinds of standards involved in interoperability between computers: formats and protocols. Formats range from "file formats" such as JPEG and PNG for images, HTML and CSS for web pages, PDFs, Word documents, and so on, through to much simpler things such as how an integer is represented. Formats specify how information is represented as strings of 1s and 0s, the basic model of information that computers agree on.
For a given string of 1s and 0s has no meaning on its own. There is no "binary language" that computers speak. There are just conventions, and those conventions are what I mean by formats. One might say that characters such as the ones comprising this article might be represented as groups of eight digits, with each character given a different pattern, and as long as the computer sending a message and the computer reading it agree on what pattern means what character, it all works nicely.
But there are several different formats for characters, as everyone who has seen mysterious gibberish like "£" where it should say "£" will know. So what people have done are come up with meta-formats that express the fact that the following bit of data is to be interpreted with a specific format. And, naturally, there are several of those...
Protocols are really just a generalisation of formats. While a format specifies how a static string of 1s and 0s is to be interpreted, protocols explain how two systems can co-operate to achieve some common goal by exchanging messages. Since those messages are strings of 1s and 0s that need to be interpreted correctly, protocols incorporate formats within them. A format is really just a protocol with only one message.
Without standard formats and protocols, computers wouldn't be able to share information. Older members of the audience may remember the time before widespread Internet connectivity made global interoperability a big issue, when it was often quite hard to get information between different systems (and even more so before the dominance of Microsoft Windows and Microsoft Office created a common target for everything else to be compatible with, and decreasing computer prices forced manufacturers to use standard hardware for things like disk drives and interconnections; try getting a file between a ZX Spectrum and a Commodore 64).
Nowadays, interoperability is... OK, but hardly brilliant. Generally disks can be swapped around freely; everything understands FAT and ISO9660. SMTP and HTTP over TCP/IPv4 over PPP over RS232 or ITU-T modem standards or wired or wireless Ethernet are spoken everywhere. JPEG and PNG and, to a lesser extent, GIF are the ubiquitous image file formats. MP3 for audio, a few different standards for video (but all with widely available players so that's OK). ZIP and MIME for multipart things, Deflate and BZIP2 for compression. HTML/CSS and PDF for documents. Plain text is the worst of the lot, despite being the simplest, due to the character encoding issues. MS Office file formats are accepted by just about any office suite, although they often come out formatted wrongly.
So it could be better - but even as good as it is, it comes with a cost. The one common thread that exists across nearly every format is that it's based on the concept of a file, which is a string of bits; with the format indicated either as part of the name of the file or by recognising the traits of certain formats by inspecting the first bits (or sometimes a MIME type header, but only a few of those are widely used, and even then, MIME is only really used for email and for delivering stuff over HTTP; the MIME type header disappears when you save that file to disk). Both of these are imperfect tests, but they work OK.
The problem is that an application that deals with an image, for example, needs to understand all the widespread image file formats that it might encounter. The author has to make a tradeoff; how much time do they spend teaching their application how to work with less and less widespread formats, before they reach a point of limiting returns in providing usefulness to their users? In practice, for widespread types of information like pictures, there are nice libraries that know PNG, JPEG, and GIF for you so you can just use the library and be done with it, and the authors of the library can focus on supporting more formats exclusively, since that's all the library is for.
But different applications use different libraries, so there's still no guarantee that any two applications will work together well. And users are exposed to all this - they don't just see a picture in their filesystem, they see a JPEG (or a PNG or a PDF or an EPS or a PSD or a PCX or a BMP or an ILBM... or a TIFF if they're really unlucky). And different types of files are likely to open up in different applications, even though they're all images, since the "what to do when the user double-clicks on a file logic" is based purely on file format, meaning that different files of the same general type can open in different applications. And when the user saves a new image in an image editor they have to choose a format to save it in, and know when to use JPEG, PNG, or PSD, for example.
This sort of all works... but it's a bit scummy. Can't we do better?
Sat 10th May 2008 9:17 pm 
Subscribe