Category Archives: Google

Who does a Non-Neutral Internet Benefit?

Posted on by — No Comments ↓

One of the greatest fights over the past few years has been over net neutrality, the fight over whether it’s okay for broadband providers to charge content providers extra for the fastest lanes on their networks. I’ll not espouse too much about the issue itself – just check Wikipedia for a primer. The question I’m pondering is this: in the event of a non-neutral internet, who stands to win in the long run?

Current broadband providers (Time Warner, Rogers, AT&T, etc.) believe that they can open a revenue stream by effectively charging content providers for access to the fastest pipes – basically, squeezing extra of money out of planned network upgrades by offering the fastest lane exclusively to the websites that will pay for it. This strategy assumes a few things, most notably that there is little interest in new parties entering the market. What if there were someone entering the market that didn’t rely solely on selling broadband as it’s business model?

There is a notable content provider who is beginning to experiment with broadband providership – Google. The Google of today provides boatloads of services that consume massive amounts of bandwidth. Google has the most to lose with a non-neutral internet – that is, unless they can tip the scales in their favor. Google could enter the broadband market very simply – have themselves be their their own best customer. Under a non-neutral internet, Google would have an incentive to provide cheap, high speed networks across the US (and, even more so in the developing world). On top of offering competitive broadband, they could offer the fastest access to Gmail and YouTube, just to name a few. By owning the network that they distribute their content over, Google would be less beholden to ransoming broadband providers, and significantly undermine them at the same time through competition.

What would a current broadband provider be able to do to compete against that? They would have to offer some other type of content (on an aging network, probably) – that would be cost prohibitive, amongst other things. The real inequity in the broadband market is that there is a lack of competition, which has significantly contributed to the idea that net neutrality is even remotely a possibility. However, a non-neutral internet could very well backfire on those that want it most. Share your thoughts!

Musings on SPDY Protocol

Posted on by — No Comments ↓

So, yet another week, and another fairly large announcement from Google. They’ve been coming pretty fast and furious lately – the open-sourcing of both Closure and Chrome OS are two fairly recent developments. However, the one this post will focus on is the announcement that Google is working on a new application-level protocol, dubbed SPDY.

SPDY (pronounced ‘speedy’) is designed as an adjunct to the http protocol, which has been around for nearly twenty years now. SPDY was designed to run atop of tcp/ip, which is the place in the networking stack that the browser talks to the web server. Hence, to be able to utilize SPDY, both the browser and the web server need to understand the protocol. However, the router need not change at all, which will greatly aid in implementation, if it’s standardized as a protocol.

So what are the features of the SPDY protocol? First, it’s faster than standard HTTP through a number of mechanisms. By default, it gzips it’s headers (and all content), making the packets more lightweight. It only needs one channel for data transfer (it multiplexes requests through the channel, which functions as a stream), so there’s a tremendous amount of connection overhead reduction versus standard-fare HTTP. The connection is designed to remain open as long as the client wants, which means that new content can be pushed from the server to the client. Packet prioritization is built into the protocol as well.

The nicest part of SPDY, in my opinion, is that it requires the use of SSL by default. This means that every packet sent over the wire is encrypted. Deep packet injection and packet sniffing are realities in the world, so a switch to secure communication is long overdue.

The roadmap for SPDY seems pretty straightforward. It’s not finished yet, but being an open source effort, a standard could be developed in a few years. Browsers and web servers can build in protocol support as the standard is still being developed. Browsers and can try to handshake in SPDY with a web server, then default back to HTTP if necessary. There aren’t many competing protocols out there, especially ones that don’t require any router firmware updates (which would take a decade to roll out, at least). Even if the web doesn’t decide to run on SPDY, the only reason for that would be someone came up with an even better idea in the meantime. A new protocol is definitely in store for the future of the web.

Google Closure

Posted on by — No Comments ↓

Google Closure

Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

Would Google Buy TiVo?

Posted on by — No Comments ↓

It’s no secret that TiVo has it’s struggles in it’s market. TiVo faces pressure from competing products offered through cable and satellite providers, and it’s a product that’s useful for watching TV, which is losing popularity as users switch more to the internet and other media, such as video games.

What does TiVo have going for it? It has decent advertising potential for it’s audience. The DVR in general has been very disruptive to television advertising. Who wants to pay big dollars for ads that people just skip over? However, TiVo can offer content tie-ins via it’s product overlays during commercials and ads it sneaks in during things like the pause screen occassionally. These ads are targeted, and more importantly, can be counted, since software can track that information. So, in effect, TiVo could easily adapt their services to stream ads sold via a third party, such as internet advertising giant Google.

A big thing that TiVo doesn’t have going for it is that it’s a pay service, and as such has a more limited appeal. If it had a strong suitor that wanted to focus more on ad revenue, the service could feasibly be set free in order to gain a wider user base. In addition, the platform could be evolved to support a wide variety of devices, such as PC’s, videogame consoles, or anything else with a nominal sized hard drive. It could also incorporate Slingbox style features, where it would allow placeshifting as well. The service could even be built directly into TVs in the future, following in the footsteps of NetFlix.

TiVo does a lot of things beautifully – it’s stellar software – but the company has a slight business model problem. I tend to believe that they could be acquired somewhat on the cheap, and could prove to be a valuable asset in the right hands.

Chrome, Freaking Chrome

Posted on by — No Comments ↓

Google Chrome

I recently wrote of the merits of Opera 9.5, which is a truly pleasant browsing experience. However, and somewhat unexpectedly, Google just yesterday released a new browser, Chrome, which I believe changes the game.

Being the browser junkie that I am, I downloaded it within hours of being released. From Google’s own admission, Chrome is less about innovation in the features arena, and more on the browsing experience as a whole. There’s even a beautiful web comic dedicated to explaining the more geeky aspects of the browsing experience, produced by the kind gents at Google

The first thing I noticed after starting up Chrome for the first time is that it renders fast. As in FAST fast. I mean, this thing screams. The rendering of Javascript is a big thing in browsers nowadays. In one geeky corner, you can see the web developers that have been working on Prototype and jQuery, wishing and waiting for a Javascript engine that doesn’t disappoint them – these guys are celebrating today, as all of us should be.

Javascript, as non-natively OO as it is and all, has been shown to be by in large the wonder of the web. Want interactive features across the web? Better know how to write Javascript. Want flashy stuff without requiring the user to install add-ons? Look at Javascript. AJAX? Yeah, that’s all Javascript. The browser has been okay on the side of Javascript – it’s always been supported by just about every browser out there, but it’s never been at the forefront. With Google Chrome (and the pending release of the new Firefox Javascript engine), it’s the star, and with great results. The web has never been faster of more responsive.

Javascript aside, Chrome seems more leveraged to provide an online platform. I can certainly see motive behind Google to go that route – it suits their overall goals remarkably. Making the web responsive enough to replace the desktop only plays into the pocket of Google, and providing the browsing experience to so is definitely in their interest. At the same time, the entire thing is open-sourced, which has never been a bad thing. The tools to work with the browser aren’t really there yet, but knowing Google I think we’re going down the right road. As a web developer, I know I’m probably being biased and unfair and all, but I just have to say thanks.