I had a couple of hours free last night, so started browsing through J2ME and Nokia docs to find what I needed to know to implement the Cellphone Rescue Button (in hindsight, I should have called it Fake Ring Button).  Guess what?  I can't implement it with J2ME.

Fake Ring Button is a very simple program.  It just waits for a specific button press and plays the ring tone after some preset delay.  Only tricky requirement is that it needs to be active all the time.  Unfortunately there is nothing in the J2ME docs that allows me to do this.

After thinking about the problem, I concluded that there is no need to change J2ME at all.  All I really need is a Next-App button on J2ME phones so that users don't have to bring up the list of midlets, scroll down to the one they want to use, and activate it to use the midlet.  With it, user's hand can memorize how many clicks is needed to run the Fake Ring midlet.

Next-App button would be useful on PDAs as well.  Two clicks to open my address book, scroll down to Mrs. Wong, and three clicks to make an appointment with her.  Bingo.

Next-App button is, IMHO, more effective than 'function' buttons with useless icons that take up more space and cost more money.  Instead of bring up your cellphone or PDAs and fiddle to get to the application you want to use, your thumb will click to your application as your hand is moving up.

Hmm.  Maybe the Next-App button can be the Power button…

Are there cellphones or PDAs that do this already?

Update #1: See the Appy post.

It's always amusing to read hacking stories.  Rob Flickhenger, author of Wireless Hacks, shows how he hacked AirPort using open source tools in Dispelling the Myth of Wireless Security.  Oh my, it is only the first chapter!;-p

This is the perfect place for David Sifry to step in and plug his Sputnik.

If you thought you could just throw in an off-the-shelf XSLT engine into your software to enhance your output capabilites, you need a security wake up call.  XML has its own set of potential security issues that must not be overlooked and XSLT is no exception.

Prajakta Joshi shows how to perform XSL transformations securely in Secure XSL Transformations in Microsoft .NET.  If you are not a .NET programmer, ignore the .NET bits and concentrate of the issues.

The world is giving up on popups because of spams.  Will we someday be forced to give up e-mails because of spam?  What about forums, chatrooms, and instant messaging?  Comments and trackback are also starting to come under assault from spammers.  Where is the line in the sand?

I used to feel comfortable with reliability of e-mails.  When I send something to somebody, I felt reasonably sure that it will be delivered and read.  That is no longer true today even with wide use of spam filters.  When I send an e-mail now, I no longer feel sure of it being read by the receipient.

Of about 300 e-mails I get each day, about 200 are deleted.  Out of 200, about 175 gets classified as spams or likely spams by my spam filter.  Since there are so many, I tired of scanning the headlines to catch false signals long time ago.  Wham.  They are wacked even though I know that no spam filters are perfect and aggressive filters signal falsely as much as 17%.

25 spams that pass through the filter undetected are found by glancing at the sender's address and the subject of each e-mail.  Are they really spams?  I have grown to care not.  If I don't recognize the sender or the subject line looks overly chummy like "Did you get my mail yesterday?", they are wacked without hesitance.  Foreign e-mails?  I wack them without mercy.

Constant avalanche of spams have de-sensitized me to the point where I no longer care if I delete legitimate e-mails.  Next step is accepting only digitally signed e-mails from known sources.  I don't think we are too far from that.  Spam filters actually seem to promote de-sensitization.  More reliable the filter is, more complacent the user gets.  When was the last time you looked inside the spam and suspected spam folders?

Taking my own attitude about e-mails and spams into account, I expect everyone to be doing pretty much what I do.  When I observed how my wife and son handle e-mails, I found that they are even more brutal than I am.  They don't even look at the subject line, relying only on the sender's address.  If they don't recognize the address, it is deleted without even a glance.

Now, step back and think about how much businesses around the world have come to depend on e-mail to do business, communicating with each other, their partners, and customers.  Then think about what the loss of e-mail reliability means.  Already, my friends in spam-suspect countries like Korea and China are having difficulty reaching me by e-mail because their messages are thrown into the spam pile.  This has direct impact on the ability of companies in these countries to do business.

We are in serious boo-boo, Toto.

Update #1: The message I was trying to convey in this post is not that we need better spam filters.  The message is that spam is not only annoying like dinner-time telemarketing phone calls, it is hitting businesses below the belt by degrading a major communication channel.

Sun engineers talk about how they are addressing web service performance issues using ASN.1 to encode XML in this Fast Web Services article.  According to the article, so called Fast is 4 to 10 times faster depending on the complexity of SOAP request and response being exchanged.

Binary XML is one of the first problems I tackled when I first discovered XML many years ago.  Since then XML spec was published and SOAP was introduced.  I was intrigued by SOAP because it shared many characteristics with Inter-Application Communication (IAC) work "Dave" and I worked on for Frontier ages ago.  Looks like the Wheel turned again and now we have Fast Web Services.

My opinion is that, while there will be some web applications which are practically only with Fast Web Services, the performance gain will be lost on most web applications.  Just look at how we have gotten used to squandering memory and bandwidth as availability increased.

Faster performance could encourage finer-grained web services which amounts to fetching a document one word at a time.  Even worse, fine-grained web services increases load on the server-side, not only on web servers, but application servers, database servers, and directory servers.  This is one case where common sense differs from reality.

While thre are ways to avoid these problem, solutions require skills, experiences, resources, and mindshares not readily available in the Lazy Web.  To best use Fast Web Services, consider it after design and implementation phase and either before or even after deployment so that your design don't end up with a built-in dependency and unavoidable waste and abuse stemming from the dependency.

KidzMail looks good (via Gadgetopia).  It would have been even better if it was web-based and provided e-mail service as well like like Hotmail so kid-appropriate filters can be come pre-installed.  Even better, expand the functionality to include other activities including blogging, IM, games, trading, and, especially important, education.

Kid's perspective affects not the UI but the functionality itself.  Take a common functionality like spellchecker.  Instead of merely underlying misspelled word and a way to correct it, each misspelled word is an oppotunity to educate the sender AS WELL AS the receiver.  Instead of correcting it, the program can use crayon like coloring to mark it and then provide correction on the side with a line drawn to the bottom where definition and related information is shown.

A weighted dictionary can be used to teach words kids are not likely to know so new words can be introduced incidentally as well as via suggestions as the kid is writing a message.

Education is a under-developed country in the software world.  Although education can benefit greatly from correct application of technology, all we do is shove more hardware at them instead of coming up with better software and interfaces that widens the teaching opportunities.

Take for example, GameBoys.  There are millions of these things and kids are absolutely attached to them, yet there are very few educational software for GameBoys.  Even a simple software like electronic flash cards could do wonders to kids.  To do this, all one needs is a GameBoy cartridge capable of running Java (i.e. JemBlazer) and a means of communication with a nearby PC like USB, Bluetooth, or even Wi-Fi.

The XML Apache Project has released XML Security C++ 1.0, a C++ library that implements XML digital signatures.  This is the first stable release.  I have used Java version of the package but haven't tried the C++ version, so I don't have any opinions other than that the library depends on C++ versions of Xerces and Xalan which tend to support latest standards at the cost of larger footprint and lower performance than other XML and XSLT implementations.

Still, it is nice to have alternatives to XML Security Library (XMLSec) by Aleksey Sanin.  Latest version of XMLSec is 1.1.0 released on August 5th.  XMLSec uses LibXML2 which was written by Daniel Veillard for Gnome project.

Both libraries are cross-platform and Win32 binaries are available.

This makes me wonder why there isn't a C++ version of Batik.

It turns out that Apache Geronimo will arrive earlier than I expected because it will ship with a forked version of JBoss called Elba, forked by a group of former JBoss contributors who formed Core Developers Network, a JBoss support company.  JBoss is crying foul saying only JBoss has the right to offer JBoss code base under non-LGPL license.

The question is who owns the copyright in open source projects like JBoss?  Code Developers Network group members have apparently written major components of JBoss like CMP 2.0, so the picture is fuzzy at this point.  As I written before, open source world mirrors what goes on in the commercial world.  It's a dog-eat-dog world.

Latest news on Apache's Geronimo project.  I agree with the BileBlog's view on the subject: JBoss takes it up the ass.  Sun's favoritism is irritating though.