Google Chrome OS - All the links you could possibly want

• Introducing Google Chrome OS [Official Google Blog]
• What does Google Chrome OS look like? [Youtube, official Google Chrome Channel]
• 5 Things Google Chrome OS will do, for your netbook [Wired Magazine]
• Will Google Chrome OS kill Windows? [Mashable]
• What Google Chrome OS means for netbooks, and why M$FT needs to be scared?[Crunchgear]
• Try Google Chrome OS yourself. Now. [Techcrunch]
• Google Chrome OS - The VMWare Image [gdgt]
• Gizmodo weigns in on Google Chrome OS [Gizmodo]
• Engadget weighs in on Google Chrome OS [Engadget]
• Ditch your hard drive, the future is the web [Wired Magazine]

Commute to Embassy Golf Links (EGL) from North Bangalore

View Larger Map


That took me over an hour to do. The stretch from Indiranagar BDA Complex to the turning to Indiranagar 80 feet road is full of potholes & pillars under construction for Namma Metro. The part from the end of 80 feet road where you turn right to get to 100 Feet Road is also time consuming, owing to heavy traffic through narrow, winding lanes.


Not a good strategy to follow at all. My commute time was 0905 - 1010 hrs. That is, by 1010 hrs, I was parked within EGL.


Here's what I did, on a whim, on the way back.






View Larger Map


This took much much lesser time. Starting at around 1745 hrs, I was home by around 1830 hrs.


Will be taking this route home from now on. If you live somewhere in North Bangalore or have to go that way one day, take this route. It's pretty nice, good roads.

The Long Tail of iPhone Apps

I recently read this article on how there are too many Apps in the iTunes App store and most of them are Crap.


This particular article is arguing that the actual barrier to entry for other smartphone App Marketplaces is much lower than Apple advertises it to be (some 100,000 apps in the iTunes App Store). This might be true, but I think the argument on which that conclusion is based, that is, their lament about most of the apps being crap, is not so sound.


Yes there are a lot of fart apps. Yes there are other apps that you or I may not find useful.
But lets not forget, what makes eBay auctions tick, what makes the iTunes Music Store tick, what makes (illegally, no doubt) peer-to-peer music downloads tick and what makes the Web in general tick is millions of people adding content that they think will be useful to others in their 'tribe'. 


Given that the content is digital, there is a low barrier to entry and consumers have infinite choice (as per The Long Tail of Marketing, Chris Anderson), so platforms that support this mass of niches are the ones that win.


Do you read all of the several million Google text ads? What makes you think they are all relevant to you? Does that mean, except for the ones that are relevant to you, all the rest are crap? :-) This simple analogy, when applied to Apps will show how the argument, that there's a lot of 'crap' in a marketplace is equal to that marketplace being doomed or useless, is flawed.


That even a control freak company like Apple has realized this in two markets - Music & Smartphone Apps is sure enough pointer that this is a way to keep from being relegated to the museum of technology. After all, Apple could have decreed, like they do in so many other areas that twenty Apps, all written by Apple would suffice for any user. They didn't. 


I don't know if we'll ever see this or not, but a graph of The number of apps sold/downloaded versus their unique rank in the iTunes App Store would make for fascinating analysis. I suspect that graph would look like a ... long tail.

A Little Revamp

Hoping to return to the blogging habit and so I started out with a simplification of the template. Hopefully this is more readable.

OpenSocial In The Enterprise

This is a short post on some very long discussions that we(me & Rajvel) had on how OpenSocial fits in the Enterprise world.

First, here are the resources we referred to -

The OpenSocial specification

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html

The OpenSocial Gadgets specification

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html

To start with I'd like to debunk the 'Portability of Gadgets across containers' concept for OpenSocial containers in the Enterprise world.

Assertion: Outside of pure social networking, portability of Open Social Widgets has no meaning. Portability only comes into play when using Open Social Javascript API's to get People, Friends, etc. This ensures a social networking widget written using OpenSocial features of the container will run on any other OpenSocial container & more importantly work in the context of that container without any code change.

In the enterprise world, where it is more likely that each provider will create non-standard extensions/features to the container to solve their business case, portability has no meaning at all. We're not after OpenSocial API's. We're mostly after a platform to enable widget developers.

Packaging: The Hidden Benefit?

Moving on, according to us, one of the hidden benefits of the use of an OpenSocial container in the enterprise is - Packaging.

As per the OpenSocial Gadget specification, there are two distinct delivery mechanisms for a OpenSocial gadget. The more often used one, where the gadget is defined in the of the Gadget XML & is processed by the container.

The other where one provides a URL to the content (HTML + CSS + Javascript) somewhere. In this case interestingly, the responsibility of packaging & hosting the application/gadget is one that the Gadget Developer must take on. The container simply uses the content from the URL, wraps it in an IFRAME and passes it on.

Constrast this with the pure OpenSocial Gadget case where the Gadget Developer knows the target container & it's (probably proprietary features). He develops & tests his gadget against this container in his test setup. Thereafter, he simply shares with the world one XML file and everything else is gloriously managed by the container! How do you like that for convenience? :-)

This also brings in a counter-argument to our assertion of Portability of Gadgets across containers being nonsensical in the enterprise context. But we would like to point out that, while the Gadget Developer relies on the portability of his gadget & therefore is comfortable in publishing the XML confident that it will run on a container that is similar to his, the gadget is NOT portable across ANY OpenSocial container in the way that true social gadgets using the core OpenSocial API's are.

You may want to think of the analogy of a Java programmer who develops an application on an X86 machine, confident (at least reasonably) that this same program will run just fine on a Mainframe that has a Java VM.

Exposing Jazz Services as Javascript API's

This is perhaps the obvious next step in the thought process. Think of a Jazz Open Social container, that has implemented a Jazz Foundation feature that exposes all of the JFS services as Javascript API's.

Is that a good idea? Or worthwhile?

Or would it be better to just ask gadgets/widgets to simply use the existing REST API's?

I can only argue that it would be convenient for widget developers if all the complexity of making the REST requests were abstracted away.

This would be like the Jazz Java SDK that is available today that does this on the server side.

The question of why we should not just provide this as a simple Javascript library comes up again. Let the widget developer use the library in whatever way they seem fit & deal with the packaging.

But then you miss out on the benefits of the pure HTML deliver of OpenSocial, as argued above. So we think this is a good idea too. It would enable rapid development of widgets for the Jazz platform, using the power of the Jazz services to any one using the JTS (which would probably have a OpenSocial container bundled in & have special features implemented).