This is an edited version of my comment to Joi's post on Microsoft's so called double-click patent.

The patent is not really about double-click but about a way to use a limited input device (i.e. a cheap button on a mobile phone) to trigger more than one function, morse code sent from user to the mobile OS if you will. It adds functionality without increasing cost nor adding clutter. What it does is map functions to like this:

Down-Up -> F1
Down-1/2sec-Up -> F2
Down-1sec-Up -> F3
Down-Up-Down-Up -> F4

and so on.

IMHO, this is not a trivial patent but a rather innovative new use of existing technology to overcome limitations of mobile devices.  Is it a general innovation?  No.  But it is innovative if you consider the context of its application and you would not think it is an obvious solution if you were the one assigned to solve this problem.

Frankly, I prefer my Next-App (aka Appy) button idea better since user doesn't have to remember the correct pattern. Instead, the user just flips apps as if flipping pages until they get to the one they want to use. In the end, users remember 'where' the app is (i.e. 3rd app) and click the button that many times as they move the device up for use.

Dave suggests that W3C use RSS 2.0 as the basis for their syndicated data activities.  I think W3C should do just that if they really want to do something in the syndicated data space.  I realize that this will lead to another clash between RSS and Atom, this time with a major standard organizations behind each, but conflicts between standard organizations have happened before and will happen again.  I sure hope a third format doesn't enter the picture though.

RSS is a reality that will not fade away for decades regardless of what happens with Atom.  Atom initiative will also not be stopped unless everyone behind it are sent to Mars (I'll go if there is a return ticket).  I tried my best to mate them but the chance of that happening is now zero, so I am now betting on both and will try my best to make sure future extensions to either formats are independent of the container format.

Update:

W3C has obligations to its member companies as well as the public. If both Atom and RSS were bidding for W3C's attention, then discussions over merits of each format has some relevance. Since it appears not, I think it makes sense for RSS to become a W3C standard considering that many of its members are already using RSS and majority of the feeds out there are in RSS.

While this will negate much of the momentum Atom gains through IETF standardization, I am betting on both horses so I don't care which format wins.

I finally got around to installing JspISAPI I mentioned over a week ago.  Since they offered 30 day moneyback, I bought and installed the full version to hook up Tomcat 5.0.25 to IIS 6.0.  It looks like it's running well and doing everything they promised.  Here is a test installation of JspWiki.

Despite increasing popularity of wiki, there is no such thing as the wiki syntax.  Instead there are many wiki syntaxes, each similar to others but different enough to prevent wiki users from learning the local dialect when they visit a wiki.  I haven't figured out exactly what factors are encouraging divergence or discouraging convergence, but wiki will remain a geeky version of the wild west unless some serious efforts are made toward standardization.

Since I don't see W3C getting out of their stubborn chickenshit mode anytime soon and IETF usually operates in reactive mode, there is little chance of standardization happening unless wiki developers, particularly those interested in commercialization of wiki technology lead the way.  The first major step should be a gathering of wiki developers, a Wiki Standardization Summit.

The goal of the summit should be clear: to agree upon and commit to a set of wiki standards on syntax, API, links, etc.  I am not interested in a summit where everyone just yaps for a few days and then leave with nothing more than good feelings.  So I think the summit attendence should be limited to those who are willing to commit time and resources to implement whatever is agreed upon at the end of the summit.

If you are interested, post a comment here.

I was at the Atom Community Meeting all day.  I had only two hours of sleep so my brain pretty much stopped working by late afternoon.  There were some good moments but, overall, it was another reminder of how a meeting can turn smart people, including me, into babbling tiredsome geeks.  Communication wasn't clear and instant understandings were rare.  Of course, my brain's capacity diminishing by the hour didn't help.

Re W3C and IETF, W3C clearly lost their bid for Atom although they made good efforts at the meeting.  I thought what W3C reps said were a bit on the cheesy side but I wasn't entirely happy with the IETF process either, like IETF WG having to use WG mailinglist for all communique and how IETF WG chairs are chosen by a IETF director.  As amazing as it sounds, IETF stunk of bureucracy, albeit one with a geeky twist.

Having to choose between techno-bureacrats and cheesy geeks financed by companies doesn't make me happy but I gave my IETF 'humm' to techno-bureacrats.  I sure hope they don't evolve into techno-rats.

I encouraged formalizing of the Atom 'group' to streamline the syndicated data standard extension approval process, but I don't think it will happen.  Neither IETF nor W3C handles extension approval process well IMHO.

BTW, Tim's post has a nice group photo he somehow managed without his glasses.

I rather enjoyed reading Gadgetopia's informal review of Joel Spolsky's book User Interface Design for Programmers.

Checkout the Napkin L&F (look and feel) for Java.  Interesting although the best way to use hand-drawn graphics is in contrasting combination with smooth lines and anti-aliased text.  They have to be rougher too.

If you need to keep track of changes in Tomcat releases, this is a good page to bookmark.

I recently mentioned XmlHttpRequest to a collegue as possible solution to his problem and found that he didn't know about it despite the fact that many DHTML apps are simply impossible to do without it.  As I mentioned before, people tend to stop looking around when they are busy.  Well, even meercats know better…

FYI, XmlHttpRequest allows you to make HTTP requests and process responses from within a webpage.  It was first implemented by Microsoft as an ActiveX object.  The shocker is that it's now considered nearly ubiquitous because other browsers support the feature as well.  For more info, here are some useful links to get you started:

• Using the XML HTTP Request object - detailed how-to article.
• Microsoft's IXMLHTTPRequest doc
• Apple's XmlHttpRequest doc

Have fun.

To run Tomcat as is on Windows Server 2003, you had to run IIS 6.0 in IIS 5.0 Compability Mode which disables all the goodies IIS 6.0 brings to the table.  Running Tomcat on another port has many downsides and replacing IIS 6.0 with Apache is not a choice either if you need to do ASP.NET tinkering as well as JSP and java servlet stuff like I do.

Behind the scene, neither Apache Foundation nor Microsoft seem to be interested in fixing the problem even though there are more Tomcats running on Windows platforms than any other platforms.  That sucks for developers like me.  So I started writing an ISAPI Extension a few months back that runs Tomcat in IIS 6.0 application pools.  As it goes, a crash project dropped on my lap and I had to drop it after spending only a weekend on it.

Now it looks like there is a solution called JspISAPI.  I can't touch my server just now, but I am going to give it a spin next weekend.  It costs $50 bucks but that's far cheaper than my spending additional 20 hours needed to debug and test my ISAPI extension.  Besides, I was planning to give mine away which would have left the authors of JspISAPI without much of a market.  As a commercial developer, I want to support other commercial developers by buying their product instead of driving them into the ground to satisfy my hippie ideals.