techno.blog("Dion")

One of the fascinating effects of working for a company that so many love to keep a look on is that you get to be on the inside watching the thoughts of “analysts”, press, and random folk.

Watching the speculation around the “GPhone” has been fun. I particularly loved it when people would come up with suggestions such as:

• “The GPhone will read ads into your ear before each call”
• “The GPhone will have scrolling ads through the screen”

Riiiiight. That would go down really well wouldn’t it! I love how some think that Google has to literally put ads everywhere to make it worthwhile. Google needs the web to keep expanding and to have more people on more devices on it. If that happens, Google will do well.

Android

So there isn’t a GPhone, but instead there is the Open Handset Alliance, or Android (for a more fun name), which is an Apache licensed open source stack for mobile. No more walled garden. This is pretty huge. I can’t wait for the SDK to get out in the open on November 12th. I wish we could have gotten more information out there today to be honest. There are a bunch of usual suspects that people who read my blog also read that are a major part of this, so I am really happy for them that this is getting out in the open!

What I am looking forward to

The applications of course. Smart location-aware services will be fun, but what I really wish I could get is for a mobile digital wallet so I don’t have to use cash/credit cards. I want to use my phone for this just as they are able to do in parts of Europe and Asia. With an open platform that anyone can build applications for, I know it is going to happen.

Here is the fluffy look at Android, but for developers, please think about what apps you would like to see on a phone, and come back on November 12th for the real announcement that we care about… the SDK itself so you can see what you can do!

I saw Microsoft’s Answer to Google Gears popup in my news feed, along with Mary Jo’s piece itself: Microsoft delivers first test build of its online-offline sync platform.

I was excited to read about the sync platform and see how it compares with the Database, LocalServer, and WorkerPool components that you get with Gears.

Instead I end up at the main documentation which makes the sync framework look nothing like Gears at all.

Instead you see the providers:

• Sync Services for ADO.NET: Synchronization for ADO.NET enabled data sources
• Sync Services for File Systems: Synchronization for files and folders
• Sync Services for SSE: Synchronization for Simple Sharing Extensions (SSE) such as RSS and ATOM feeds

This looks interesting from a client-side perspective, and I want to take some time to look at the sync API itself and see what good stuff we could potentially use in Gears. Microsoft has had to do various sync protocols over the years, so I am sure there is a lot to learn, but this isn’t a Gears rival in its current form.

To say it has been amazing to watch OpenSocial come together in recent months is an understatement. OpenSocial isn’t a product that Google came up with, it is a standard. At first you have to get a large number of groups at Google to agree to the core ideas, and then came the partners. Working with the partners has been a real trip too, and the speed of development as well as decision making is truly astounding to me.

I knew that the press will jump on this as “a Facebook killer” or “Facebook vs. Google”, but that is b.s. Applications that are social can be better and we have only seen the beginning. F8 has opened up a lot of eyes, and many companies are going to innovate in this space.

Take a look at what OpenSocial really is. Check out the APIs. Understand that this is the beginning of something. The first set of APIs mesh closely with Gears, as I talk about on the podcast with Patrick Chanazon. There are a few core services (people, storage, activity stream) that have GData endpoints that you can access, including the core JavaScript library which is how development is generally done at the moment. The libraries will look especially familiar to Google Gadget developers, as they are similar in philosophy. To me, this isn’t about some huge new platform, but rather a set of components that people can use. Gears is the same way. You have three key components (as of now): WorkerPool, Database, and LocalServer.

As a Java guy Patrick and I even joked about how it felt a little like some of the Java standards in that this isn’t about “write once run everywhere” but is rather “learn once use everywhere”. OpenSocial has the concept of “containers” where these APIs run. This is where container partners such as Bebo, Ning, Hi5, a ton of others, and, oh MySpace come in. opensocial.newDataRequest() everywhere.

The API is at a point where there is value to using it, and having one API that containers implement allows a developer to develop against it, knowing that they can move their app around. On the other hand, containers can add to the API to give specific information that you may want. For example, if your container has a lot of music information you can share that, and if you are building a music app, that could be a good thing. There is a core set of APIs, and containers will add their value on top, just as WebLogic did through deployment descriptors :)

Back to Facebook. I actually don’t think this is a bad thing for Facebook. It validates the market, and will grow the entire pie. Now even more developers will think about developing social applications. Facebook has a lot of users hanging out on that network, and they are the kind of users that are used to installing applications at this point, so I think that a lot of developers will write applications than run across FB and OpenSocial and beyond. Having MySpace along for the ride is big, and maybe Facebook could join in too and we could create a true standard that the community pushes forward.

It has probably stirred up the FB folk too. They have known that this is coming. Competition is obvious, and I hope that OpenSocial can help push Facebook into getting increasingly open too. They sometimes get a bad rap there, and we keep forgetting that they opened up F8 only *months* ago, and are still working out what it means to open up a platform like this. It will take time and there are a lot of hard problems. As great as collaboration is, there is also a PC vs. Mac debate here. Facebook can run like the wind in their own direction. This could end up being a fantastic product. On the other hand the group could also run quickly as they have been doing, and instead of being stuck in standards hell, they could produce something just a great, across many containers.

Should Facebook implement OpenSocial? I personally think so. Why?

• It will be a lot easier to grow the developer pool on OpenSocial as you can just get new partners and hitwise grows
• If people developer cool apps on top of OpenSocial, why wouldn’t you want them to run as applications in Facebook? It could also allow developers who aren’t fans of FBML to use different methods of building their applications.
• Facebook can still innovate as a top notch container that has a huge amount of users
• It would negate “us” versus “them” talk.

It is going to be an interesting ride, and I hope that people don’t get sucked into the press too much and really check things out. With everyone jumping on board, I wonder what is next. Can we get to the world that Brad talked about? Will we get a federated world? There are some hard problems to solve.

Resources

• OpenSocial APIs
• Campfire One
• Marc Andreessen on Open Social, showing it, and reporting from the trenches
• TechMeme linking to all of the crud out there ;)
• The initial press release

I have seen the Google Code team churning away under the inspiration of DeWitt for some time to get to where we are today. Google Code launched a redesigned site that is so much cleaner and gives developers access to so much more. I love the fact that we both ate our own dogfood, and some open source variety. DeWitt puts it well here where he talks about how we have grown:

One of the most exciting things about the redesign is that everything you see here was built using technology and APIs that are available to everyone. The pages we’re serving don’t rely on any secret back-end tricks; the site is built on plain HTML, JavaScript and CSS, each using our public APIs. In fact, all of the techniques used on Google Code can be duplicated on your own site.

For example, the search results pages use a combination of the AJAX Search API and Custom Search Engines. The homepage gadgets use the AJAX Feed API and Google Reader feeds. The videos are powered by the YouTube API, the blogs by the Blogger API, the events powered by the Google Calendar API, the metrics by Google Analytics, the forums by Google Groups, etc., etc.. And we’re pleased to use jQuery, the wonderful open source JavaScript library (not ours, we’re just fans), to help power each page. Stay tuned — over the upcoming weeks we’ll offer detailed articles and tutorials about how we built the various parts of Google Code using open technologies.

Remember when you would go to a huge list of APIs? Now more takes you a great product page which gives you a lot of context. Search is a first class citizen (which makes sense… Google and all) and you now have great suggestions and a fantastic use of CSE. I can’t wait to show you more of the innards via interviews with the team…. now that they can have a bit of a breather.

The breather won’t last long though, as this just the beginning. When I look at the thoughts for the future I get really excited. Google Code got a lot better today, and will go to a new level soon.

I love launch days :)

I was really excited when I logged in to Gmail and saw the new settings:

I think this is my number one feature request for Gmail, so it is great to see it role out. Since Gmail is tag/label based, it isn’t as easy to implement IMAP as it may seem, so good job dev team!

The reason that I personally care is that I have been able to do this for my corporate account:

And now, I can finally do the same for my personal email account. Check out the automatic labels that you get.

I just posted about the Sun announcement on Java Applets 2.0 (even if the PR folk kept telling us it was an “update” not an “announcement”).

The web community tends to poo poo the applet. We scoff at the startup time. We complain at the cross browser issues that went against the point. We moan at the speed. We groan at the image mouseover examples.

However, if we get off of our high horse for a minute and think about what a world where Java in the browser was actually decent, we get an interesting picture.

If the plugin could be in control of the cross browser / platform issues, then it could allow us to write rich components that work on all. We could build and register a really nice file upload component for example that takes over type=”file” to do a lot more. We could use JNLP (or something else) to register the modules, and when we get winners, could even standardize them.

If we then think about SQLite databases in the browser. We could actually use Hibernate to work with it. The JavaScript / Java bridge is already decent, and could get even easier / better.

If the Java Plugin is done well, it could become a platform to build on. This is a big if though, and there is the spectre of Java 1.x in IE looming out there. Is there a way to get around that though?


// beginning of the plugin simply does
if ie and freaking old Java 1.x
run the installer
end


As I think about this, Gears and Java could actually do some interesting work together.

Man I love Greasemonkey. I am a heavy user of Google Code, and there are a few links that I wish were on the site for my use cases. I could bug the team to get these links added, but to begin with, I wanted to add them for myself to see if I really needed them.

I have changed two pages, first the home page:

All I did here was add a link to my open source projects page. Before hand, I would have clicked on Project Hosting and futzed around, or just remembered to type /u/ and gone via history. Now I have a big bold link on the top right thanks to the simple userscript.

Secondly, I have changed the project pages to add:

• A tab to go directly to the trunk of the Subversion repository for the project. This saves 3 normal clicks
• A link back to my projects on the top right, for jumping between projects. Ideally, I would change this to have a drop down of the projects.

This simple userscript does the deed.

The Ajax API team has taken the Ajax Feed API and created a simple Dynamic Feed Control that lets you input some feeds, and you get a nice control in a few styles (vertical, vertical stacked, and horizontal).

The Ajax APIs often show the pattern of giving you a very low level API, a simple control and then finally a wizard to generate all of the code for you.

The wizard also uses the new feed discovery mechanism itself, and here it is in action:

Business Week shows that journalists love to talk about the death of something and the rising of the other. This time, in The Desktop Takes Center Stage Again they say things like:

And companies such as Adobe (ADBE) and Google (GOOG) have released or are testing products that let Web developers build desktop versions of online services and sites. Google launched a group of Web-to-desktop developer tools known as Gears in May (see BusinessWeek.com, 5/30/07, “Google Gears Up to Take Web Services Beyond the Web”). “Everybody wants to be on the desktop,” says Martin Kay, chief executive of online music site Finetune, which recently introduced a way to make the company’s music-streaming and recommendation service available on the desktop. “People tend to forget about Web sites.”

Gears isn’t about helping “Web developers build desktop versions of online services and sites”. The whole point is that Gears gives the browser new powers!

It adds a small set of key functionality that developers can build upon, just as they did on XMLHttpRequest.

This isn’t about having people developer desktop apps as different apps. It is about making the Web a better place….. and one that can work to some extent offline.

Gears and AIR are not the same thing. They suit very different needs, and can complement more than compete. I hope that over time this becomes more obvious.

One thing is for sure…. neither the desktop, nor the Web, are close to being “dead”.

Nicholas Jitkoff normally hides in the shadows a little, as alcor. They finally persuaded him to come out and speak about Quicksilver.

Quicksilver is the FIRST application that I will install on a new Mac, and it was great to here about it from the horses mouth:

Quicksilver hides almost unbounded power beneath the interface of a keyboard-driven … all