Google Gears

This is actually the second time I've written about Gears. The other time, Flock ate my post. I wasn't too upset, since I was using a daily build of "Sulfur". It's much better (in terms of feature set) than the current 0.7 version of Flock, at least when it comes to blogging on Blogger because it supports Blogger labels. Anyways, back to Google Gears.

I gave it a try (via Google Reader of course), and was not too impressed for one simple reason. I have to tell it to "go offline." So I guess the idea is that I know I'll be offline later, so I will "go offline" now, thus downloading content to read later. Ok, that's fine, but not very useful. It requires too much planning, in my opinion.

It's really not that big of a deal for Google Reader. But clearly Gears has the most potential for other Google Apps that have more direct "offline" analogies: GMail and Google Docs. The choosing to go offline thing would be silly for either of these.

With a Gears enhanced GMail, I would expect to always have a copy of (at least) my most recent email. I'd expect to be able to search it, too, but that's another story for another day. For Google Docs, I would at least expect to have an offline version of all my "active" docs. For both of these apps, I would expect to have these things all the time, seamlessly. Anything else is of very limited value in my opinion.

So I am left to assume that Google will enable this kind of seamless enhancement via Gears, but they just haven't figured it out, yet. I think that makes the most sense. If they had figured it out, I'm sure they would have enabled it with Reader, even though it's not quite as essential for Reader. In fact I'll wager the reason they launched with Reader was exactly because they didn't have the above use cases solved, yet.

One other Gear related thing. I was fascinated that Adobe seemed to be hanging around for the launch of Gears. It's interesting in a lot of ways. First, Adobe already has something similar, but far less powerful than Gears: Flash Shared Objects. Gears and its database make SO's look silly. Second, doesn't a Gears enabled Flex application provide everything that an Apollo application could promise? Sure, an Apollo app could be "heavier", have a fancier UI maybe, do more with local files, etc. Finally, I got the feeling that there was a Adobe+Gears announcement that didn't happen. That something that was supposed to be ready for Google Developer Day, wasn't ready. That's why Adobe was there.

Opening Up Flex

Interesting news on Adobe open sourcing some of the Flex platform. Here is a cool video from the Scoble Show on the architecture.

For the past couple of years I've thought Flex had some clever concepts behind it, but it was going to be collateral damage in the ascension of AJAX. Why? It was too closed on multiple levels. First, to take advantages of its greatest strengths (continuous, bidirectional communication between client and server) required a proprietary Adobe server. Second, the development tools were also proprietary. It's hard to quickly prototype something in Flex, unless you've already made an investment in it. That is poison for innovation. That's also why so much more innovation occurs in Java and PHP rather than .NET, but I digress.

I don't think the above equation has changed with Adobe's new open source initiatives. However, it seems like maybe they are more concerned with competing with .NET/XAML/SilverLight as browser/desktop hybrid technologies. There might be some potential in that, but I still don't think they have the right strategy for it.

Imagine if you were at a mall and you were hungry. There were several hamburger stands in the mall. The hamburgers were pretty cheap and pretty good, and there was a lot of variety. There was one place (Microsoft) that sold hamburgers and fries, but it was very expensive. Now let's say you wanted to sell hamburgers and fries as well. You could make a hamburger and fries that were in similar quality to the sole hamburger+fries vendor, and maybe charge a little less. Or you could make a hamburger that could stand on its merits to the many hamburger-only places, and charge a price similar to those guys. It's riskier, because there's so much competition, but you could still charge a nice premium for the fries. If people start buying your hamburgers, there's a good chance some will splurge on the fries too.

Adobe has chosen to charge a lot for both the hamburger and the fries, just like Microsoft. It's a safer strategy, but with a lot less upside in my opinion. They have to hope that Apollo will lead them to success, because otherwise my original thought will still hold. Flex will be a casualty of Web 2.0.

Adobe Apollo and Flex

With all of the recent hoopla around Adobe's Apollo, I decided to give it a try. From what I've read, you should be able to develop a web application and Apollo will give it an "offline" mode. So you could just build a typical web application or even an AJAXy one. I figured for the full Adobe effect, maybe I should finally dip my toe into the Flash waters.

So I downloaded a trial version of Adobe Flex Builder, plus the Apollo SDK and extensions for Flex Builder. It turns out that Flex Builder is built on Eclipse. That made me optimistic. Not only do I think Eclipse is a very smart platform to build on top of, but I know Eclipse really well. One would think that my familiarity with Eclipse would help me to be productive with Flex Builder.

A direct consequence of the Eclipse heritage is that there are two installations options for Flex Builder. You can install it "standalone" or as an Eclipse plugin. I have a lot of Eclipse plugins, but I've had some bad experiences with "bigger" plugins in the past. For example, when I was at Vitria, I was using Xml Spy for debugging complex XQuery expressions. I had the professional version of it, and it gave you the option of installing an Xml Spy-Eclipse plugin. I thought "cool, I can do my XQuery debugging inside Eclipse!" That may have been true, but I'll never know because it really hosed my Eclipse installation. I had to wipe it out and rebuild it. Rebuilding an Eclipse installation that involves lots of plugins is a real pain.

So needless to say that when confronted with a commercial application wanting to install itself inside Eclipse, I always decline. So I went with the standalone installation of Flex Builder. It was pretty quick and clean. One thing I noticed was that installed a JRE. Thankfully it only installed it inside its installation directory and it did not mess with any environment variables. I've been burned by Oracle installing its own JRE and then putting it on the path or even redefining $JAVA_HOME...

Still you would think that the Adobe installer would be a little smarter. It would be easy to detect if Java is present on the path. If it is, then don't bother installing a JRE and just use the system's JRE. Also, digging around I quickly found that the JRE they included was the HotSpot 1.4.2. Talk about old! Hopefully they'll skip 1.5 and move straight to 1.6. They may not get much advantage out of 1.5, but the speed improvement on 1.6 (particularly for a long-running process like an IDE) is definitely worth while.

Enough complaining about the installation... Here's what it looks like fresh out of the box on Windows.


Pretty similar to Eclipse. It seems like the big difference is the squarish windows. Of course the options in the menus are a lot different. They are very simplified with just options for creating Flex projects and objects. They did leave in the Software Updates, so you can easily install Eclipse plugins. That is very nice. All in all I am looking forward to building something Flashy.