N810 demo video from Nokia

Nothing too special about the web page, but the video gives lots of good angles and pictures of accessories. Sure would be nice if they used that GPS and a database to help find some WiFi hotspots. Too bad it doesn't have WiMax or EV-DO.

read more | digg story

Accessibility is the killer mashup/webos application

After watching Douglas Crockford (of Yahoo and JavaScript fame) plea for Google, Microsoft, and others to participate in a mashup summit and reading some of the feedback around the web, I realized the critical application use-case is still missing.

Someone in the Q&A brought up a good example of a mashup implemented today in an undesirable method due to security reasons: Facebook accessing your GMail/MSN/... contacts to request more members. Contact sharing between applications is an excellent use-case for mashups, but I don't see it as a driving application. Certainly it gets to the heart of Crockford's talk: security is an excellent application for the Google Gears WorkerPools. If you are like me, you'll still be left thinking about how everyday web consumers will be motivated to download Gears, instead of walking down the questionable path of simply giving applications like Facebook access to all of your potentially private information.

Mashups are the most interesting innovation in software development in decades. Unfortunately, the browser's security model did not anticipate this development, so mashups are not safe if there is any confidential information in the page. Since virtually every page has at least some confidential information in it, this is a big problem. Google Gears may lead to the solution.

Security is important and is critical to the growth of new mashup applications and I'll be happy if that alone brings us worker threads and off-line support, but I think the killer mashup is the one that makes all of this great data exposed through APIs and structured web pages and makes it accessible in new ways.

Mark, of diveintoaccessibility and diveintogreasemonkey fame, who I admire for his vision of accessibility wrote in his blog post "if wishes were iPhones":

I don’t understand this continuing obsession with buying things that you need to break before they do what you want.

And with this thought I am reminded that the killer mashup/webos application is the one that takes all of those immensely useful web services out there and makes them measurably usable. And by usable, I mean giving the user control.

Mobile 2.0 Conference

I'm thinking about trying to attend the Mobile 2.0 Conference on October 15th in San Francisco. Anyone have comments about this event? If there were a handful of people interested in chatting about how to enable creation of scalable web services generated from mobile/embedded devices, I'd make a point of going.

No server, no satisfaction

There's just no satisfaction for the casual home user who wants to collaborate with friends. Even when dealing with a problem that has been solved many times over, it is really difficult without a server of your own and a fair amount of programming. The problem I'm talking about is planning events on a group calendar.

There is a group of somewhat over 25 people near where I live that frequently gets together to play outdoor roller hockey. We play in a parking lot in one of the area parks or offices. We have a mailing list on Yahoo, but most people are just copied on a repeatedly used e-mail thread. On that thread, the subject line is typically changed to match the proposed day and time. Every week, we all bombard each other with e-mails to make sure that enough of us are coming out to play. This has actually worked fairly well, but there have been some significant exceptions.

Sometimes we don't meet our threshold of 6 players and additional e-mails go out to entice people to sign-up to play. Calls are made. Threats are discussed. People who previously agreed to go attend might decline since they don't want to risk trying to play hockey with only 3 people. Chaos ensues.

One of they guys who used to come out regularly created a really simple sign-up page on a website. The site accepted a name, e-mail address, and phone number to sign-up for a given game. The name is listed beside the entry for that game. The e-mail was used to send out the "game-on" or "need-more-players" notification a few hours before the prospective game. Phone numbers were included to speed up the communication.

The application worked quite well and was simple-minded. Entering the same sign-up information twice would result in being removed from the list. The phone number and e-mail information had to match, providing a tiny amount of security from folks simply removing everyone from the list. No verification of the entry was done, but you can imagine a simple verification code being provided via SMS to the mobile phone number if we ever started to have problems with that. Life was good.

He stopped playing and his site stopped working. We were back to using e-mail. A few folks reminisced about the good 'ol days when we had our own web server. I own the domain name, so I decided to bring back the sign-up sheet. Where should I host it?

I don't really like the idea of pointing people to my home computer, so that's not my first choice. I don't really like the idea of paying for a full-featured (LAMP and/or Ruby enabled, ie. scripting and a database) hosting service just for this hobby. This is just calendar data! Why should I need a web server to do something that Yahoo and Google provide for free?

Our mailing list is on Yahoo, so I looked first at their group calendar. It was a disastrously complex to use and didn't provide any of the custom features we had with the much simpler web app. Similar problems were had with Google's calendar and Evite. The most fundamental issue with all of these calendaring solutions: they required account creation and login to utilize.

I tried to see if I could do something with static hosting, but it seems even Amazon's simple queuing service doesn't seem to work without having a dynamic host. At this point I gave up, but I'll get back to this application yet.

Still don't get the whole WebOS thing?

I've gotten a bit smarter about explaining why there will be a sort of emerging web operating system to the people who inquire. For example, I've started calling it a "web services kit", instead of an operating system. Today's tech savvy minds can accept the idea of yet-another-SDK, whereas the idea of a web operating system is either tainted by the webtops or seen as inconceivable and unnecessary delusions to compete with Windows, Linux, or OSX.

What I haven't leveraged enough is the great summary of web service APIs provided by ProgrammableWeb. From their simple scorecard, you can get a quick overview of the categories of popular services and some of the key players. Ask yourself what sustainable advantage do any of these players have within their service space. Don't get fooled, it isn't an easy question. Keep in mind that standard service definitions are coming into existence for most of these services, such as XMPP for chatting and OpenID for identity. Take up the exercise to look across these service APIs, look for winners, and look for emerging standards.

Comfortable? Now, realize that it is only a matter of time before there are standards-based implementations of all of these services. Sure, it might take a while, but it'll happen.

If you are quick, you might be sighing and thinking to yourself, "what about the data?". I'm glad you asked, because that is really the point. These services are all about controlling access to data and looking for ways to monetize it. You might stumble over the idea that on-line office applications involve an incredibly complex pile-o-code, but then you'll remember that you already have 2-3 other viable choices of office applications to which you already had access. Over the long-term, it is all about the data.

Still don't feel like you're any closer to accepting the idea of a web operating system? That's okay, as long as you recognize the benefit of something that provides you with the capability to control and monetize access to data and some sort of well-understood integration layer back into your application. You'll come around when you start thinking about who you want to own your data.

BarCampHouston

I'm heading up to BarCampHouston today. I don't know what to expect and I haven't had any free time whatsoever, so I won't put on much of a demo or presentation. I'll be happy to share any info on P2P collaboration and my Maemo SDK EC2 image, if anyone is interested. I'm also looking forward to simply discussing toolkits for building web services (web operating systems).

By the way, I've moved my EC2 script over to http://sdk-ami.garage.maemo.org.

Boot your N800 Maemo SDK today with Amazon's EC2

I really appreciate that someone has created VMWare and QEMU images for running the Maemo SDK. Unfortunately, my machines, both Mac and PC, are typically too busy with other stuff to allow me to quickly fire-up a virtual machine image that will chew up all my computing resources. Instead, booting up a machine from Amazon for about $0.15/hour or so is affordable enough for my N800 development. No more downloading a 1.5+GB image; EC2 users can instead just share an image and a boot script and be up-and-running at a known-good starting point.

Of course, the first step was to get an EC2 (and S3) account. I waited almost a month for my EC2 account. At some point I'll figure some way to let other people just rent a machine from me to make it easy, but that'll require a bit of thought and management. For now, head on over to Amazon, request an account, and they'll get to you eventually. There isn't any monthly fee or hidden costs; you just pay for the time, bandwidth, and storage you use. As long as you copy your work off somewhere else, such as by using Subversion hosted by code.google.com, you can shutdown without having any recurring fees.

Once you have an EC2 and S3 account, you'll want to download the EC2 command-line tools and your access identifiers.

The next step was to choose the Linux image I wanted to use as my starting point. Personally, I'm a Gentoo fan because I think Linux has an excessive number of binary-compatible dependencies on the C library and Gentoo solves that by recompiling every new application, instead of needing to update your C library to match the binary-compatibility requirements of all your applications. Of course, that makes application installation slow and Maemo itself uses the Debian package model, so Debian or Ubuntu make the most sense. However, Amazon supplies some nice reference images on Fedora Core 4 that might simplify my life around issues like ssh login security when the root account password can't be secret. Nothing is easy, so I found an Ubuntu image that has reasonable documentation on how it was created such that someone could redo this all with a better supported AMI in the future.

At this point, the issues started to pile up and I decided my best hope was to document my steps in scripts so that I can reproduce them with a better starting image and make corrections that people point out to me. I decided to the Google Subversion server I mentioned earlier to host my script at http://code.google.com/p/maemo-sdk-image/.

I used a Mac to run my script, but I plan to eventually make it run on the N800 itself or on a Windows PC. Right now, the script uses bash, which isn't natively on either the N800 or Windows. Also, the Unix-style version of the EC2 command-line tools also utilizes bash. I think the solution for both is likely to install bash.

The access identifier information ended up placed in a subdirectory called 'secrets' under where I ran the script. These secrets end up getting copied temporarily to the EC2 images for the purpose of bundling them up. I exclude that directory from the bundle.

I say 'images', because I end up working with four different EC2 images in the script. The first one is the base Fedora Core image that Amazon makes public. The second one is a bare-bones Ubuntu Feisty image that can be boot on EC2. The third one is patched to be self-bundling. The fourth one actually contains the Maemo SDK. The third and fourth could easily be combined, but I am still inching along.

In theory, you can run all of the steps using 3 separate calls to the script:

1. ./build_maemo_api build-feisty
2. ./build_maemo_api patch-feisty
3. ./build_maemo_api install-maemo

I think the first two should work reasonably well to create a self-bundling Ubuntu image, but I haven't run them exactly like that to test them out yet.

The third step certainly won't work. One issue is that the Nokia binaries require you to agree to a license, so you'll need to do that part manually. This also only gets you to version 3.1 of the SDK, so you'll need to update that as well. There are also several steps missing before the image is really usable, such as setting up the X server and VNC server to allow you to view the emulated N800 screen remotely.

Please feel free to post your comments here or on the wiki on how to improve the script. I won't hesitate to utilize your inputs on the script hosted on the Subversion server.