I recently posted an item "cellphones and barcodes, and computers for everyone" to kragen-fw, containing the following paper:
"Designing an Architecture for Delivering Mobile Information Services to the Rural Developing World", by Tapan S. Parikh and Edward D. Lazowska, http://www2006.org/programme/files/xhtml/5507/5507-parikh/5507-parikh.html Probably they will give up on the "cache" idea eventually and give the cellphone owner control over which applications are installed on the phone and which are not. This project inspired me to several thoughts: - most of what they're using barcodes for could be done just as easily by typing four-digit codes on the phone keyboard. - the Anoto Fly Pen is also a camera-based data entry device, and things like it may have some benefits in directness. - It might be feasible to put actual applications into a barcode rather than just field identifiers. PDF-417 barcodes can hold several kilobytes of data --- I think up to 6 or so. Here are the bzip2ed sizes of some things in my devel directory: 6352 bytes the stack-based graphing vector calculator (DHTML & MochiKit) 8890 bytes the mailreader I'm using (Python & curses) 19264 bytes the full-text email search engine I posted to kragen-hacks a month or two ago (Python) 4699 bytes the SK-combinator graph-reduction evaluator I posted recently (DHTML & MochiKit) 1733 bytes the thing that synchronizes my mailbox onto delicious (Perl) 616 bytes the thing that backed up and restored my old cellphone (Perl) 7326 bytes the bug-tracking system from WowBar (Twisted Python & DHTML) 7063 bytes the thing I posted recently that efficiently synchronizes my mailbox (Python & CGI) 688 bytes the thing that reformats my text tables for me (Perl) 1195 bytes the zooming text-file pager I posted to kragen-hacks some years ago (Python & Qt) 2397 bytes the filesystem expanding/collapsing outliner for file selection that I posted to kragen-hacks some time ago (Python & curses) 1046 bytes the GTK oscilloscope program I posted some years ago, without its voluminous comments (C & GTK) 4745 bytes the older full-text email search engine that only searches in one file (Python) 3541 bytes the Condorcet election simulator I posted a while ago (DHTML) 3000 bytes the queryable triple-store I posted a while ago (DHTML) 1164 bytes Dave Long's incredible data: URL quine (DHTML) 2422 bytes the approval-voting event calendar (Python & Nevow & CGI) So it's probably possible to put fairly interesting functionality into a PDF-417 barcode, given a sufficiently rich execution environment for it to draw on. However, multimedia applications might be harder. In 1999, I wrote, "LPC-5 compresses [voice] to 2400 bps, or 300 bytes per second [leaving it comprehensible, but not recognizable]." I'm not sure I got the name of the codec right --- anyway, it was one of the codecs from Speak Freely. At this rate, 6 kilobytes is about 20 seconds. A good-quality small JPEG is about two-thirds of a byte per pixel, so 6KB is about 80x100. - There was an augmented-reality project a while back called, I think, "Neko" in which 2-D barcodes were captured in real time from a video camera, and their three-dimensional position and orientation were used to position and orient a 3-D rendered model overlaid on the video image. The effect was that there were virtual three-dimensional objects standing on top of the barcode. (All I can find is the video: neko.mpg, 3149020 bytes, md5sum 9c5a1b5d085db8668d0b5d9e4de0f09e.) Similarly, for data-entry applications, you could use barcodes to tell the cellphone which parts of the paper had which meanings, removing the need for manual re-entry of the data. This is pretty similar to Scantron forms and "fill in the bubble" test sheets, but without the specialized hardware. - I think modern inkjet print heads can print at 2100 dpi, and I think they move across an A-size sheet of paper something like 20 times a minute, which is at least 6000 pixels per second per nozzle. Suppose you put just one of those nozzles (out of the hundreds or thousands in a printer head) into an optical mouse; this allows you to store data onto the paper in dots and dashes at, ideally, 6000 pixels per second. As long as you keep moving the mouse in a smooth line, it keeps writing data as densely as cheap paper can take it. The same optical mouse can read the data back again by gliding over it, or you can use several frames from a bigger camera, or a full-sheet scanner. There are several possible failure modes that can be worked around in software: - part of the line gets lost (goes off the paper, is too jaggy to trace, gets smudged by the mouse bushings): apply ECC to the data, and then permute it so that each ECC codeword consists of many widely separated bits. CDs work this way. - the line is scanned out of sequence: divide into "packets" or "sectors" and embed the sector numbers frequently in the data. - bit errors: ECC. If you use either several nozzles or several cameras, you can see the line as it's being written and adjust the bit rate according to the paper's capacity. Such a device could also produce recognizable 2-D images in a "rubbing" sort of way, as I had suggested earlier in the "illuminated pen" kragen-tol post.
