Google

One of the features that I desperately miss form my Outlook-user days is the ability for my email client to use custom signatures. I tend to use a lot of pushing and pulling between my email accounts, so there does arise the need often to have my work-related email signature to show up in my personal email, especially when I am using delegation to reply from the personal email to the work email.

Gmail does provide you the ability to attach signatures to all outgoing email, like any self-respecting email provider does. But it does not allow you to either use multiple signatures that you can pick at the time of sending or use HTML in it (without using Signature Tweaks from Labs) in it.

The workaround for this is to not use signatures. Instead, turn on the feature called 'Canned Responses' in Gmail Labs. You can find it in the Gmail Labs settings tab. Once enabled, compose a new message and create your new signature there and save it as a canned response, which you will see as a drop down menu in the same column that has the attachment controls. You can add multiple options using the same process.

Next time you want to pop in an email signature in any of your outgoing email, select one of the options from the canned responses and you are good to go. It is as simple as that!

Google recently launched Mobile Sync, a product that allows a variety of mobile phones to sync up with Google's services. To say it mildly, Google really blew it. Even in the early days there were errors that stopped the sync from working and there was no response from Google's end.

Today, anybody who tried syncing was faced with a new error which said "unable to open database." What has happened is that the URL given for the sync (https://m.google.com/syncml) has disappeared from Google's servers and it is returning a 404 error at the moment. The hapless clients that try to connect to the URL, obviously, can't find it and errors out saying the database cannot be opened.

It is understandable that this a new product and I have often given Google a great length of rope with their new product launches, but turning off URLs like this without any intimation is really not done. Even if it is a human error, how can something as simple as this happen?

For a company that is very serious about entering the enterprise space such mistakes and lack of communication goes not augur well for its future. I hope Google will pull up its socks on this front, sooner than later.

Skia is a graphics library made by Skia, a company Google had earlier bought. The library is used in Android and Chrome and both platforms are already target deployments for Google Gears. Nevertheless, it is an interesting development as to why it was checked in. You can see the check in log here.

The check in had a bit of a horrific impact on getting Gears to build from the current SVN version. The paths are horrifically mucked up between ./third_party/skia/include/code and ./third_party/skia/include. The actual SVN tree has a lot of missing files too, you will need to manually copy them over from the websvn cached copy to get it to build.

The bad news is that, even after getting it to build, even the SVN version of Gears (0.5.12.0) does not work on anything upward of Firefox 3.1. Will post updates if I see any change in the situation.

Camino, Google Gears

it is now fairly well documented as to how Google is stepping up its measures to bring in additional revenues from any possible source in these times of strife. Looks like we have yet another instance of another such initiative being pushed out by Google.

At least until January 2, 2008 (well, that is the latest working copy of the page to be found on the amazing Wayback Machine), Google Apps did not have a sign-up flow that did not spare any effort to push to the paid version in your face. I believe this was the case till at least April 2008, which was the last time I had migrated a domain to Google Apps, but I don't have any real proof beyond my very unreliable memory to back up that assertion.

In its earlier avtar, users had the choice to pick the package they wanted from the landing page itself. Compare with the state of affairs now. The URL, http://www.google.com/a/ itself redirects now to http://www.google.com/a/help/intl/en/admins/editions_spe.html. Moreover, It takes you about four clicks to get to the free version, while the paid version of the platform is the one which is shown to you by default.

It is amusing really to see changes like these, for they are very reminiscent of a time when you would have to hunt around, leaving a long trail of clicks behind you, in trying to download the free version of Real Player or Winamp in the years closer to 2001.

I guess we can, with this, bring on yet another slew of articles that will poke fun at the 'Do No Evil' motto at $GOOG.

There is much blogging glee underway in the content/tech/biz media about the viability of YouTube in terms of money it is making at this point. Details in posts here, here and here. I think they all have gotten it wrong in different ways and I will try and explain how.

YouTube has been and still is a game changing play. Which means that the way in which it is changing the audio-video content business has no precedents for us to refer to. I will confess to being one of the doubting Thomases when Google acquired YouTube, but I have changed my opinion about it. But, coming back to the main point, the way in which this will play out has no previous instances to refer to. So, trying to call it on the basis of what we have already seen is not going to cut it.

You have to be very foolish to think that YouTube is a short-term play or that it is going to be cheap to run. Then again, it is considerably cheaper for someone like Google, with their extensive peering agreements and dark fiber ownership, to run the service than for a standalone player to accomplish it. Google's peering is already quite significant, with 130 prefixes, which is about half the size of someone like Limelight, which has about 300 prefixes.