As a tribute to Bob Frankston’s rant on Bluetooth, here’s a quick thought on my shiny new Canon MP780 multifunction printer. (RIP old Canon S400 — you did good service at the battlefront.) As with all the Canon gear I’ve bought, it’s a tour de force of modern product design and manufacture. But there’s a problem. I use a Linux box as my home web, print, VPN, email and file server.
I can print from my laptop in raw mode via the CUPS printer spooler system — the drivers on my Windows XP laptop assemble the image and the print server just ferries the bits. I do lose access to things like notification of low ink by being mediated in this way. I can fax and copy, because they’re stand-alone functions. But I can’t scan unless I plug the printer into a Windows box. There are no Linux drivers for the MP780 from Canon, and the SANE project hasn’t yet reverse engineered one for me.
Rather than the usual Slashdot-style “Windoze sux and Canon don’t get the joy of open source” diatribe, let’s think about it a bit. Engage brain before opening mouth, as my Dad used to say. A bunch of bits want to get from the printer to my laptop. The printer happens to be plugged into the USB port of my Linux server. Moving bits isn’t complex. If my Linux server appears to be in the way, we’ve got an architectural problem.
And that problem is indeed that people’s can’t just settle for layered connectivity. USB, Firewire, Bluetooth and friends confound and befuddle several different things. One aspect is electrical power — the provision or regulation thereof. Bluetooth’s excuse for living is that Wi-Fi is too power-hungry and IP too costly an overhead. Another is the negotiation of end point identifiers and routing. Plus security. Yet another is media access. And finally we have service discovery and invocation.
These “vertical” technologies bundle these functions together tightly. If my requirements don’t match their anticipated use, I can’t remix my own solution. In this case, my laptop is more than one connectivity hop from the printer. Game over! So rather than create a generic networking protocol for device discovery (a-la Sun’s JXTA technology) we get a specialised, optimised version that fits the use case that some design committee thought up in a dull anonymous conference centre vaguely near an international hub airport.
Various non-functional requirements tend to drive people towards these stovepiped connectivity solutions. Speed, power, reliability, form factor. But often technology has marched on so much between conception and deployment that speciailised solutions are no longer cost-justified.
I’m aware that Canon et al design these printers with minimal memory and processing power and shuffle as much of the effort (and cost) onto the PCs to which they are attached. Most modern printers are the paper-spewing equivlent of the Winmodem software-based modem. But that still doesn’t mean we need a smart box attached at the first hop that has to understand scanning and printing.
So what should my printer do? It should be network-aware! If printers had a religion they’d be monotheists — the only God is the PC to which I’m attached. C’mon — join the network age! Pantheism is the new deal. Ideally there’d be an Ethernet port. But confronting the deployed reality of USB-rich PCs, the printer just needs to be able to make itself network addressable — via some form of tunnel if need be, and to be able to negotiate among multiple client devices trying to access it at once. Purely a software problem, no need to increase the device cost. Make the connectivity IP-based and standardised, so if I want to tunnel some IP link over PPP over a USB cable, it’s all out-of-the-box stuff for any sensible OS I attach the printer to. I have reason to belive our society has crossed the threshold where such things are possible! Yeah, I might still only be able to use Windows and MacOS as the edge nodes. But in our stupid home network, it really shouldn’t matter how the bits get from A to B. Don’t want to have a print spooler inside the printer with the associated memory cost? Make it a discoverable network service, or get the PCs to co-operate in buffering data, Peerio-style.
The same thinking infects us in other ways. For example, we have PATA and SATA to communicate between hard drives and motherboards. Yet more and more storage is migrating into the network, mostly as cheap Network Attached Storage (NAS). Why isn’t my local hard drive just a cache to my persistent cloud? Why must I manage these devices at the physical layer at all? What are we doing still worrying about the “C Drive”? Why don’t hard drives just come with a gigabit ethernet port and a power socket?
USB embeds other dangerous assumptions. Your mouse and keyboard is only supposed to work with one PC at a time, apparently. Despite loads of people wanting to control multiple PCs at once. (I do.) Thus we end up with all sorts of hacks to get around the lack of direct addressability. Your microphone is supposed to talk to only one PC. But what if I want to wander around the home and have the converation follow me, with a microphone in every room? More incompatible, non-interoperable hacks to simulate real network connectivity. Why can’t my microphone be accessed by more than one PC? And so on. Every time you think you really have a concrete case for a single-hop network technology someone comes and snarfs it up with some damn counterexample.
My Canon printer has a USB port on the front to attach a camera for direct photo printing. Help! More stovepiped connectivity! My phone talks Bluetooth, not USB — so I can never print from my phone, despite having a laptop with Bluetooth attached to the network attached to the Linux box attached to the printer. We can make packets traverse the globe in a few milliseconds, but crossing my study within line-of-sight is an impossibility!
I say all this because Bob’s writing really pulled the scales from my eyes. I thought I “got” this stupid network stuff. But I still casually accepted these stovepiped connectivity solutions sprouting in front of me! For instance, the more I use Bluetooth, the more frustrating the inbuilt limitations become now I know how things could be better and different. Imagine Bluetooth was just an IP connection that searched for a local web services directory (répétez après moi: UDDI and WSDL). How much more powerful and flexible it would be!
It all kind of reminds me of Bob’s single hop signalling essay, where he laments the framing problem of spectrum regulation that comes from a legacy mindset that radios should send data from A to B in a single hop across a single, exclusively-accessed channel. Drop the outdated assumptions, and your spectrum metaphor dissolves away like a Cheshire cat, just leaving the happy smile of raw unmediated connectivity.
Posted by Martin Geddes at 01:24 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/629.
You're surprised?
Bluetooth was designed by (mobile) Bellheads...but don't let the mobile part get in the way....they really are Bellheads in their hearts and minds. Any wonder then it is as confusing as it is...and as inflexible.
IP designed by Netheads...'nuf said.
Posted by: at December 9, 2005 11:19 PM