The buzz and crackle of mating unrelated new excitements: Experiences with Amazon web services, Project Atom, and a J2ME camera phone application that acts as a bar code scanner to transform all physical goods into mere floor demos.
This isn't anything so coherent as an essay, just a loose collection of things that I've found exciting over the past few weeks, akin to a jar of fireflies that may congregate into a single holy shining globe of brilliance, or on the other hand may just as likely wink out without further notice...
Smarter indexing == More value for books I already have
Amazon allowing me to search the text contents of a gazillion books makes the old books in my own library more useful. If I vaguely recall a passage, a quote, a character, a witty line or somesuch but can't remember the location, I need only to execute a few text searches in Amazon to locate the source and find the exact page number. It's like an instant index. Great for religious debates, standardized tests, arguments with the in-laws, cheating at trivia contests, or just general casual re-education.
Here's an example that queries Ed Roman's book Mastering Enterprise JavaBeans to see if he had any mentions of SOAP.
Personally I dislike the notion of having to go to the amazon.com site and digging down into specific HTML-based entries to begin such a query, but fortunately for me Amazon seems to sympathize; how long 'til we see MS Office plugins that can take advantage of this feature via a few RESTful requests to Amazon while you're working in Word or Outlook, or perhaps even a few SOAP-based requests to new operations in the Amazon web services? Amazon has taken another step closer to becoming the central commerce engine for mobilized and service-oriented applications everywhere. By aggregating Google and Amazon's offerings, a developer could have intelligent, query-able access to a content repository unlike any previously assembled. If the apps ran on unobtrusive and ubiquitous mobile devices, such a device could become not a replacement for books (so much folly, wasn't it?) but a sort of satellite aid for enriching the reading experience, working along with books. If only there were a pleasantly simple yet extensible way to develop such apps...
I don't intend to pick sides between RSS 2.0 and Project Atom, because as a product vendor I think it's best if both are successful so that I have more interesting things to support and simplify in tools a layer above the standards. I have been spending a good deal of time playing with Atom lately, though, so I'll mention my experience with it -- meaning no disrespect to RSS 2.0 (things Winer and Ruby tend to get religious, and religion tends to get violent; this caveat is more necessary than some may know).
That said... wow! A simple, extensible format is emerging for content publishing and syndication, editing, and archiving that relies on the RESTful approach of using HTTP GET/POST/PUT/DELETE for its operations, replacing the blog world's current mixed bag of RSS/XML-RPC/WebLog APIs/HTML forms. Nicely extensible via reasonable namespace support, easily managed through tools and XPath/XQuery engines, supportive of multiple locales and content types, etc. Based on asynchronous doc/literal web services rather than RPC. All this is to my liking. My purpose here is not to explain what it is or consider its status, though. If you haven't seen it, browse through the wikki. I mention it because it helps me get to something I've been wanting for myself...
Offline Queries of XML Schema-compliant content delivered from Amazon, Google, Exchange, and...
What I want is my Amazon and Google (and others, but keeping it to just these two for simplicity's sake) services to return data in the form of a content model that conforms to something like Atom, making it easier for tools and client platforms to manage it intelligently. I want to be able to execute an XPath expression or a full XQuery statement in some sort of explorer window (that is, a file window in any OS or device) to grab relevant data. And I want to be able to update that data even while offline, and have it later synchronize (if using Atom, via a POST or PUT) when I reconnect. And I want the data to find me automatically based possibly on some subscription settings, and I want... well, I want a lot of the things that ex-Microsoft and current-BEA visionary Adam Bosworth speaks about when he talks of a Web Services Browser. Atom takes a pretty good stab at suggesting a content model and an HTTP-based API for approaching such things, stopping short of features or modules such as intermittently connected data and services, which of course we could add (or hijack from WS-Whatever) and integrate using Atom's namespace support. And at Macromedia I have been spending a great deal of time helping design a client-side container named Central to manage just this sort of functionality on the client, and see much headway there as we evolve the web browser (more on Central another time). It will take the right remote services, content model, friendly API, and client container to make it all come together.
I fully admit that I'm too enthusiastic to think clearly about this just now, but am comforted by the knowledge that my more familiar cynicism will certainly return -- and that's when I'll probably be able to get something real implemented. In terms of actual code using these sorts of services, though, I did pull together something based on these thoughts and the realization that...
Camera Phones are Barcode Scanners!
A few weeks ago I built my first real J2ME application: a simple app that uses the Mobile Media API to grab a picture of a book's bar code, perform some image recognition to rip the ISBN (you can also just enter the ISBN or UPC code manually if you don't happen to have a camera phone), send the ISBN to Amazon, and receive reviews and pricing info on the book. I provided the option to add the book to an Amazon cart, assuming it's less expensive than the copy I happen to be holding, and can even make the purchase via One-Click from the phone if I so desire. Mostly I just use it for the reviews so far, and I had to do some hacking to get the One-Click and purchase stuff to work (Amazon's RESTful and SOAP services don't expose enough features yet), but I found this to be a good use of the available technology to create a service-based mobile app that's not just a game (no offense to game designers). Works great on my Nokia 3650.
Better: I could hook this up to the service endpoint for an open source UPC database I recently located, and theoretically do the same for all types of products, not just books and CD's and DVD's. All the world's for-sale goods become mere floor demos.
Sadly, however, my friend Jeremy Allaire has informed me that this idea has been patented, which I should have guessed. I'm only a mobile developer by night and weekend, and haven't the inclination to battle some angry company that intends to market the thing, even if my version ends up being decently strong. Ah well, it was still a terrific experiment and it left me bitten by the mobile bug -- I see many mobile apps in my future. Not sure what my official day job employer will think of this...
And, and, and...
A couple of fireflies escaped the jar: Location-Based Services such as Zingo are chief among them. I'll recapture that one in some future entry. Meanwhile, even if nothing comes of these random thoughts, I feel great excitement, which is non-trivial in a world in which I was staring at implementing another wave of J2EE specs, the Red Sox broke my heart, and a fierce Autumn storm prematurely defoliated our New England trees. I'm just too mobile to be dragged down by it all -- there's random exciting stuff flying around out there!
> I was wondering how you did the image recognition to get > the ISBN number from the barcode, since I thought that was > impossible in MIDlets.
I actually ship the image off to a server proxy (just a servlet with a couple of business delegates) I wrote, which controls the image work; the proxy also accesses the remote services and strips them down to a minimal format for the MIDlet, so the pull parser in the MIDlet need do very little. The proxy also does a super-basic job of caching requests and responses, per Amazon's requirement. It's all fairly low-tech, to be honest, probably nothing to write home about. I did start working on a version to handle the image recognition on the device, since sending images across the wire can get expensive, and I think the ideal version might be something that performs basic cropping or partial filtering on the device and ships the result off to the proxy, which would finish the job. I'm not sure that it cannot be done entirely on the device, but even if it could it would likely eat enough processing power (equating to battery life) that I don't think I'd want to cut the server out of the picture.
I'm assume the patent applies to the UPC aspect, and not the barcode recognition? Did Jeremy say who holds that patent? I can think of other uses for on-board recognition, if it can be made practical... perhaps an ASIC...
Not sure if you check this blog any longer, but I thought I'd try and reach you through here first. I stumbled on to a wired article on bar code capture through camera phones, and you were mentioned in the article.
We have a proprietary application we are interested in using this technology. We're not pleased with ScanBuy's software pricing (per phone). It just won't logistically work with our business model.
I don't know if you pursued enhancing the technology you developed any further in the last 15 months, but if you still have interest, we have an interesting application for the technology.
You can reach me via email at email@example.com if you are interested.