Didier hacked together an implementation of URLCall on his new Python-enabled Nokia phone.  Cool!  He also used the word 'dial' to describe the concept which I think is better than 'call'.  So a new name for the concept could 'DialWeb' except that it's being used for another telephony project. 

[Update:  Why not come up with an entirely new word by smashing Dial and URL together?  Diurl!  I might have heard the word before in my past lives…perhaps during the French Revolution?  😉 ]

Anyway, unless I misunderstood, his implementation runs entirely on the phone, thus requiring phone number to URL database to be on the phone.  My ideal solution would use a server-side database accessed via a HTTP GET.  URLCall client on the phone needs to know only one URL.  With multiple HTTP redirection, you can even set up a hierarchical directory infrastructure on top of HTTP.

URLCall (level 1) looks at the first number and redirects to one of 10 Level 2 URLCall websites.  Level 2 URLCall websites looks at the second number and redirects again.  So on and so forth.  Net result is a sort of poor man's directory infrastructure spanning the globe.

A more practical version would reserve the top rows of the phone pad (1,2,3) and '0'  for special uses (i.e. anything start with 1 maps a personal URL like my bookmarks page) and then use the remainder plus the next three numbers to decide which Level 2 URLCall directory to route to.  Numbers starting with '0' is a way to call local numbers.  I think three HTTP redirects at the most is needed to address all the websites in the world with phone numbers.

Here is a bug that I wasted untold hours on.  sendAndLoad is a method available on Flash 6 and later feature that sends and receives URL encoded name/value pairs.  For example:

var in = new LoadVars();
var out = new LoadVars();

in.onLoad = function (success) {
   if (success) {
      // got response
   }
};

out.somedata = 'hello world';
out.sendAndLoad('hello.cgi', in, 'POST');

In the above example, I've used an anonymous function to handle the response.  Unfortunately, Flash MX 2004 generated Flash movie doesn't call anonymous function onLoad handler if the movie output settings are Flash version 6 and ActionScript version 1.  The workaround is simple: use a named function like this.

function loadHandler (success) {
if (success) {
      // got response
   }
};

var in = new LoadVars();
var out = new LoadVars();

in.onLoad = loadHandler;

out.somedata = 'hello world';
out.sendAndLoad('hello.cgi', in, 'POST');

During my breaks, I've been thinking about ways to improve mobile user experience.  One rough spot is the need to type in URLs which are typically ASCII which is awkward to type into a phone.  One way to get around this problem is to use phone numbers.

This is how I see it working.  Each website offering mobile contents or services gets one or more URLCall (pronounced Earl Call) numbers which are phone numbers.  When the number is called, the phone recognizes the number as a URLCall and, instead of making a real phone call, it opens the web browser and opens the URL mapped to the phone number.

URLCall Recognition

Special number prefixes or a set of non-existent country codes configured into the phone can be used to recognize URLCalls.

URLCall to URL Mapping

Many solutions are possible.  Here are two:

DNS Solution:

DNS-like services are used which maps phone numbers to URL instead of IP address to domain names.

HTTP Redirect:

Phone simply points the browser to a known URL with URLCall as a parameter:

http://urlcall.net/phone2url?1234567890

URLCall.net service looks up the number and performs a HTTP redirect to the mapped URL:

http://somewhere.com/mobile/welcome.html

A less glamorous yet more practical solution that will work with existing phones with only minor changes is to program a single button to open the browser to the URLCall.net website.  So all user has to do is click on that button and type in the number.  This approach removes the need for URLCall recognition which I like.

NOTE: URLCall.net is a fictitious domain which I made up to illustrate the idea.

UPDATE:

First implementation of URLCall by Didier!

Bruce Schneier reports that SHA-1 is broken.  While the supposed newly discovered weakness in SHA-1 algorithm reduces it's strength by about factor of 2000, SHA-1 is still strong enough for a few years at least in most applications.  However, if you are using SHA-1 to produce artifacts whose validity is irrefutable over a long time (i.e. digitally signed birth certificate) or is of high value (digitally signed deed to a 25-story building in downtown Tokyo), then you got a problem because they are basically sitting ducks waiting to be forged.

Odd.  Am I the only one who  wants to use HttpOnly cookies from servlets?  Looks like Jetty and Resin are adding HttpOnly support but what about others like Tomcat and WebSphere?  And why isn't Sun adding it to the Servlet API or at least open it up to allow custom cookie extensions?

Evil Twin (via Dave Winer) Wi-Fi vulnerability is another example of typical boneheaded security designer's mindset: single-side authentication.  While Wi-Fi users have to identify themselves to protected Wi-Fi routers, routers don't have to identify themselves to the users.

The first killer-app for mobiles is the phone calls.  I believe static downloadable audio contents such as music, audio books, and podcasts will be the next killer-app. Only design problem is sharing one battery for both critical (phone calls) and casual (listening to audio) uses which calls for smarter power management and more powerful batteries.

Great user experience and clever hardware design is where Apple excels at so I expect Apple to introduce iPod phones within a year or two at the latest.

Unfortunately, screen-based applications and dynamic audio contents, driven by voice browser technologies, will continue to struggle in the near future due to tedious user experience.  Mobile killer apps must be available at the user's fingertip, not hidden behind a wall of patience.

The last time I've done any intense development work for mobile devices was 4~5 years ago.  At that time, I've looked at Palm, Pocket PC, J2ME, and WAP and concluded that mobile platforms were not yet ready.  Last week, I've looked at the mobile devices and OSes again.  My opinion is that it's still not ready despite the amazing change in capabilities and capacities.

The main problem that prevents emergence of killer apps on mobile platforms is that applications are treated as second-class citizens, placed in a straight-jacket and pigeon-holed.

To receive or make a call, one just flip-opens the phone or press a button.  To use an application. one has to navigate around a typically hierarchical tree of functionalities.  Some devices have separate buttons for built-in applications but they either cannot be remapped to another application or controls for remapping is buried and lost in that confusing tree of functionalities.

In addition, functionalities are not tightly integrated and offers wide array of modal experiences depending on where you are on the tree.  On top of the default phone mode, browser mode, SMS mode, e-mail mode, address book mode, and various preference modes, each application has its own mode.

Before killer apps can emerge, mobile platforms must be changed drastically, removing modes and allowing applications to add their functionalities without being boxed in.

Online identities of today are just a bundle of information submitted by a person, stored somewhere, and protected somehow, typically with just password.  You can get free email accounts and use that to sign up anywhere claiming to be anyone.  Not only you but anyone with the password can as long as they are polite enough to restore changes they made before you notice.

And what does all the new identiy technologies do about this problem?  Basically nothing.  But they are great for efficiently sharing untrustworthy data among interested parties so the user don't have to deal with countless passwords and forms.  What do the identity services get out of it?  They get to lord over that pile of untrustworthy data.  Fantastic.

What I find really amazing is that all that keeps this house of cards from flopping is: honesty.

IMHO, the missing piece in online identity is identity sponsorship by businesses based on transaction history.  They are like little boyscout patches except they are issued by everyday businesses with which the user had extensive business with.  The user's identity is the shirt onto which those patches are sewn into.

For example, Bank of America or BlockBuster could issue me a patch that I've been their customer for more than a decade.  They can do it to retain customers or as a new source of revenue.  There is no privacy issue either since the patch could just be a set of numbers, each representing a trust vector.

Hmm.  We need a fancy term for this.  How about Trust Syndication?

Elliot Rusty Harold's XOM 1.0 is finally released.  XOM is an XML object model with some interesting features:

XOM is fairly unique in that it is a dual streaming/tree-based API. Individual nodes in the tree can be processed while the document is still being built. The enables XOM programs to operate almost as fast as the underlying parser can supply data. You don't need to wait for the document to be completely parsed before you can start working with it.

XOM is very memory efficient. If you read an entire document into memory, XOM uses as little memory as possible. More importantly, XOM allows you to filter documents as they're built so you don't have to build the parts of the tree you aren't interested in. For instance, you can skip building text nodes that only represent boundary white space, if such white space is not significant in your application. You can even process a document piece by piece and throw away each piece when you're done with it. XOM has successfully processed gigabyte sized documents without breaking a sweat.

Most importantly,

XOM strives for correctness, simplicity, and performance, in that order. XOM is very easy to learn and easy to use. It works very straight-forwardly, and has a very shallow learning curve. Assuming you're already familiar with XML, you should be able to get up and running with XOM very quickly.

Since I've implemented quite a number of XML object models myself so I am looking forward to browsing through its innards.