This may seem a bit random for this blog, but Web 2.0 is only as good as the tools that deliver it.

Using Web 2.0 applications may have been viewed through the lens of either Microsoft Internet Explorer or Mozilla Firefox (on a Windows machine), but now a third alternative has come forward and I think it has just taken the lead in the “horse race:” It’s Google’s Chrome web browser!

I’ve been noticing that IE and FF have routinely been consuming 150M and even up to 300M on my Vista machine. Both feel clunky and slow.

But I’ve been using Google’s new Chrome browser and I’m shocked how fast and snappy it is — AND how stable, even though it’s still in “Beta.” A quick check of RAM consumption shows it taking only 20-30M of RAM for similar usage scenarios as IE and FF.

Try it yourself and see what you think: http://www.google.com/chrome

SMS and GPRS are certainly not new, but I haven’t seen much discussion comparing/contrasting them, so I thought I would briefly summarize what I know about them here.

Location tracking devices that use one of the various cellular wireless networks will generally employ either SMS, GPRS, or sometimes both for communications.

SMS is best known as the communication approach used by teens around the world for “texting.”

GPRS provides the same IP communications protocols as the Internet on the cellular wireless networks — HTTP, TCP, UDP, etc.

There are some interesting trade-offs between these two communications methods.

SMS has limited message size, no more than about 160 bytes after headers, but this may not be a problem for most applications applications where the device simply sends location and a few other data items. Most service plans charge by the message, favoring infrequent (for example, once-per-day) reporting scenarios. But SMS messaging has more robust coverage and will continue to work on the fringe of rural coverage and other weak-signal scenarios when GPRS will not.

GPRS has many advantages: It supports standard IP protocols, so the same tools and infrastructure that have been built to support the Internet can be used in your GPRS-based solution. Also, lots of people are familiar with these technologies, so the pool of technical talent is large. Since most service plans charge “by the byte,” GPRS is probably a better choice for higher-frequency reporting scenarios (for example, hourly or whenever the device moves a certain distance). Typically, developers have more options to optimize and reduce cost with GPRS than they do with SMS.

The funny thing is that most carriers and most radios support both, but not all service plans and technical support for these options are equal. So, not only must you make the right technical choice based on the inherent merits of SMS and GPRS, you need to be sure your carrier supports your choice well.

Google Maps is an awesome resource for web-based GPS-tracking applications. And with so many ways to collect GPS locations these days, it makes mapping those GPS locations fast and simple. But sometimes, you can have so many GPS locations on a Google Map that it can be hard to see the one you want.

The GMaps API has tools to control what location markers you see, but the default options may not be what you want or expect. You can find many examples on the web on how to include a GMap using whatever tools you favor, but eventually, you will probably use Javascript to create a GMarkerManager and use “addMarker” or “addMarkers” to put GMarker objects in it either one at a time or as an array, respectively. So far so good…

But if you read the fine print, you will discover that a collection of GMarker objects, no matter what order you create them in, are placed on the map in such a way that the “southerly” markers are on top of the “northerly” markers. That means that if you have a sequence of markers representing the locations of a car, for example, that is traveling from south to north, then depending on your zoom level and the frequency of GPS reports, you might find the older GPS location markers showing ON TOP OF the newer ones.

Now, to me, the intuitive thing is to show markers on the map the same way you would if you were using a pen and paper, plotting dots as you got them. If so, you would see put ink for the newest dot ON TOP OF anything else that is already on the map. Right?

So now what? Well, in the same fine print about the default marker display — the GMarkerOptions class documentation, to be specific — you will find that GMarkers can have an attribute called the “zIndexProcess” which is a Javascript Function. This means you can override the order in which the markers are displayed.

Now, in my case, I have a simple “for” loop to create a set of marker. The loop has an index to enumerate my GPS locations and create GMarker objects to add to a GMarkerManager object for my map. I simply use this index to create a “zIndexProcess” function when I create the GMarker. It works like a champ!

Here’s some code that shows how it works. Mouse over the points to see the times. The “NEWEST” and “OLDEST” points are so labeled. Note that the trail of GPS location travels from south to north, so the “northerly” locations should be on top, but are NOT by default…

HINT: If you right-click in the titles of the maps you can “View Source” in most browsers to see how this code works. It’s self containted, and you can experiment with your own copy.

As I see it, the leading M2M equipment manufacturers are fighting for market share by chosing one of two device design philosophies. A few are even trying to place their bets on both. Ultimately, the market will decide their fate. The question is whether the market wants “closed” devices with predefined, though configurable, functionality or whether it wants “open” devices with the flexibility to be programmed for a specific application.

In the M2M world today, there are “closed” devices that are configurable, but not programmable, and some that are “open” devices that can be programmed. The largest volume of devices seem to be the “closed” type, but they exist to satisfy several very specific business needs — examples include sub-prime car loans, teen tracking, and various specialized security applications.

When I talk to people who have application ideas, they are very creative about how to use the existing “closed” devices to help them solve a business problem, but often the “closed” device can only get them to the starting gate. So much of their “wish list” requires special features that can’t be justified in a general-purpose device. However, if the specialization can be defined in terms of software and not additional hardware, suddenly the “open” device options become much more attractive.

The tradeoffs are pretty straightforward. “Closed” devices benefit from larger production runs leading to lower costs per unit. With larger numbers come more tested scenarios leading potentially to greater stability and robustness. “Open” devices currently sell fewer numbers, have higher costs, and have been tested less. BUT they also can acheive a wider range of functionality and address a larger number of business solutions.

If “closed” devices are winning on price, volume, and robustness, “open” devices could surge forward by continuing price reductions and the availablity of effective over-the-air programming (OTAP) options, leading to the potential for even greater volume and the hardening through real field use.

Which will win this time? There are serious contenders in both camps. I’m not picking winners here (yet) and am holding off (for now) naming “front runners.” But I’m enjoying watching the battle. Stay tuned…

I keep running across M2M scenarios that would be amazingly great, except for one problem. But the “one problem” is different for each scenario.

If only the device/radio/sensor were under X dollars…

If only the data communications plan were under X dollars a month…

If only you had GSM coverage in XXX…

If only LEO satellites had a latency under X seconds…

If only we could integrate with SAP/IBM/etc…

If only the application were infinitely configurable in seconds…

If only you could get Costco/Walmart/PetCo/etc. to carry it…

THEN we would have the perfect solution!!

I’m enjoying chanting the Ublip mantra of “easy, easy, easy…” because my toes are sore and bloody from stubbing them against so many rocks and saying “if only…” But to be easy, you have to focus on simple. And to be simple, you have to work with what is, not what would be nice to have.