Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!
Chris Prince posted about Gears turning one year old. It was launched at last years Google Developer Day, and here we are at Google I/O a short year later.
One feature that they were lacking was the ability for MySpace users to actually search their MySpace messages. To go through mail, users have to page through all of their messages until their find the right one. Not optimal to say the least!
They could have tried to do search on the server side, but it can be a very expensive operation, and when you are at MySpace scale, you have to choose your battles.
With server side search out, they looked at doing the work on the client. They ended up with a Gears powered solution that not only searches, but gives back results in real-time as you are typing it in. This means that you can stop typing earlier, as you find what you are looking for.
The MySpace team has been a pleasure to work with, and were very fast to put the pieces together of an Full Text Search datastore, and the WorkerPool to offload the search without hanging the browser.
This is yet another use of Gears that isn’t just about “offline”, which we are seeing more and more. In fact, Chris Prince gave a talk yesterday that showed prototypes and examples of Gears that people are exploring. There was exciting stuff in there such as:
Multiple File Upload: Using the File System API, Chris demonstrated a multiple file upload experience. Selecting multiple files, finally!
Resumable File Upload: He then showed a YouTube mockup that showed uploading multiple files, seeing their status, and after a connection died showing how the file resumes and doesn’t start from 0% All using a ResumableRequest that sat on top of the Blog API and HttpRequest
Find nearby stuff! Next up was a demo that let Chris search for beer, resulting in local places around the Moscone Center. This example used the Geolocation API which uses GPS, Wifi IDs, Cell IDs, and IP address to work out where you are
Notifications: Love the Windows toasters, or Growl-ing on the Mac? Chris showed notification examples
I was sitting on the tube a few months ago in London when I looked up to see Matt Mullenweg, Om Malik, and another nice chap whose name escapes me. A little random to bump into them in the middle of London, but we were all in town for the “Future of Web Apps” conference. I had the fortune to chat with Matt a little about Gears and Wordpress. The marriage of which would make me a happy man as I use both technologies on a daily basis (this blog and Ajaxian both run Wordpress).
Brad Neuberg got to working with the Wordpress team, and after a short IRC session they had great progress. At first it can seem daunting “Oh man, won’t it be a ton of work to rewrite Wordpress to work offline?”
Speed Up!
This leads us to this post by James who did an “svn up” recently, and saw new support for Gears which lead to some pleasant surprises:
As a side note and introduction to what has been sped up, here’s a little rant.
I personally LOVE the changes that were implemented with WordPress 2.5.
But, some of the new features (and features I’ve just started using now that I use the Visual Editor) just aren’t as cool thanks to the not-so-great internet speeds in South Africa.
For example, if you want to create a link. Every time you click the link icon in the editor’s toolbar, it has to download the same stuff over and over…
Well, it looks to me like the WordPress Google Gears implementation has solved that. The link and the “insert embedded media†popups are now instantaneous!
Thank you to whoever decided to do this.
It also seems that switching between each “pane†in the admin section is a LOT faster… Believe me, working on the South African tubes (via iBurst), this makes a HUGE difference!
I am really proud of the Gears team whenever I open up Google Docs, Reader, Zoho, or any other application that uses Gears to let me access the application while offline. There have been situations where it really saved me, and offline is an important boundary.
However, Gears is so much more than offline, and it is really exciting to see “Speed Up!” as a link instead of “Go Offline?”
This is just the beginning. As the Gears community fills in the gaps in the Web development model and begins to bring you HTML5 functionality I expect to see less “Go Offline” and more “Speed Up!” and other such phrases. In fact, I will be most excited when I don’t see any such linkage, and the applications are just better.
With an embedded database, local server storage, worker pool execution, desktop APIs, and other exciting modules such as notifications, resumable HTTP being talked about in the community…. I think we can all get excited.
Kudos to the Wordpress team for finding a great way to increase the performance of their great application, and I can’t wait to see how you use Gears in the future.
One of the examples that Ben and I give in our State of Ajax talk at Google I/O today revolves around form history.
We were thinking about the case for Undo on the Web that Aza Raskin is proposing and it got us thinking about the usage patterns of form data.
An example that got me was the Address Book application on the Mac. I find myself storing past addresses in the general “Notes” section at the bottom, but what if history was built into the system so I could go back in time? This could be a nice metaphor in general that goes beyond undo.
I took this use case and put together a working example that uses Gears to store the history locally so it can be speedy through the history.
The slider component comes from Script.aculo.us, and you can check out all of the code.
In the video below I show the application in action and then do a quick code walk through:
This is just the beginning of course. A slider if fun, but it would probably be more usable if it was simply left and right arrows that click through the versions, or at least putting tacks onto the slider.
I have talked before about the desire for a Notification API on the Web. As a Mac user, I would love to see Growl from JavaScript, and there have been libraries written from as far back as protoGrowl.
The difference is between a JavaScript API that does notifications on the desktop, versus trying to get little custom notifications inside the browser window itself. I am talking about the former.
What was interesting was the implementation side, and the paths Brian went down to get this working. I asked him for his thoughts, and he wrote up the following:
One of the biggest new features in the latest version of Growl for Windows (v1.2 alpha) is the ability to receive notifications from websites running in your browser. i spent quite a bit of time working out the best way to handle this functionality and thought i would share my thought process.
since Growl can already receive notifications over the network, i figured that it would be easiset to build the Web-based notification system on top of that. Growl receives network notifications using a simple protocol over UDP. ok - first hurdle: browsers and javascript dont do UDP, so i figured i would have to go with some kind of add-on. i wanted the solution to work cross-browser, so Firefox extensions and ActiveX plug-ins were ruled out. i also wanted the solution to work for the broadest range of people, so i didnt want to write a custom add-on (a la Gears). i knew that Flash and Silverlight both had networking support, but neither can do UDP, so they were both quickly ruled out.
that left Java as the only other widely-installed cross-browser extension at my disposal. Java obviously has robust networking support, including UDP, so i headed down that path. the biggest problem now was that i have never created a Java applet, nor even written a line of Java code. but the syntax was familiar enough, and i was able to find some good sample code on the net that i was able to mash into a tiny applet that could send UDP packets. it actually worked brilliantly, and i was quite happy with myself for solving the problem so easily.
but of course, it was not that easy. there is that little restriction known as the 'same-origin policy'. running the applet on my localhost worked great, but as soon as i ran it from any other location, i would get a secuirty exception. i tried all kinds of combinations of values for the CODE and CODEBASE attributes, including file:// urls and even encoding the applet code as a data: uri, but i was thwarted at every turn (as so i should have been - the entire reason the restriction is in place is to prevent what i was trying to do). right before i gave up on the applet idea, i had the realization that if i could serve the applet up from the local host, then it would be able to communicate with the local host later. but configuring and installing a simple web server just to serve up an applet seemed like overkill. alas, the Java idea was a dead end.
so, it was back to the drawing board. what did the browser have access to that could bridge the gap? i decided to try a custom protocol handler, similar to the Itunes Music Store (itms://). a couple of simple registry entries and i had my growl:// protocol working. i had a helper process that sat in the background and everytime a growl:// url link was clicked, the browser would pass it off to my handler, along with the original url. i decided that i could pass any information as a JSON-encoded string in that url information. again, it worked great and seemed to be a good solution, but that made me sure that it must have a drawback. turns out the drawback in this case was that there was no way for the browser to know if the protocol handler was installed on the user's machine - if the protocol handler was installed, the browser passed it off nicely and all was good, but if the protocol was not installed, Firefox would present a dialog saying something like 'firefox doesnt know how to open the address because the protocol is not known' (IE and Safari both just returned a 404-type page). since i wanted websites to be able to use the communication feature if the user had Growl installed, but not mess up the experience if they didnt, this was a deal breaker.
i was starting to run out of ideas at this point, but i remembered the idea of serving up the Java applet locally. while i was pondering the details of that solution, i thought 'if i am going to have a local server to serve up the applet, why not skip the applet and just communicate with the local server?'. so i implemented a very simple webserver that runs when Growl is running that can be accessed at something like http://localhost:9889. the idea of using the url to pass JSON was repurposed and soon i was able to pass JSON-encoded Javascript objects to the local server, which code then parse the data and handle it in real application code. i couldnt use ajax to communicate with the local server (same-origin policy strikes again), so i decided to use the hidden iframe technique. i wrote a small js library to abstract everything out, so now you can write code in Javascript that almost mimics the code you would write if you included the Growl libraries in you application code:
Growl.notify(someKindOfNotification, 'Notification from the web', 'this is the description', Growl.Priority.VeryLow, false);
of course, receiving notifications from websites opens up the possiblity of spam and other noise, so applications that register from the web have their notifications disabled by default (thus requiring the user to explicity grant the notifications they wish to receive). but that is another topic for another day.
Ed: I decided to make today, "Extend the browser through APIs Day"
var geolocator = new navigator.GeolocationRequest();
geolocator.request({
success: function(location){/* We've got the location! */},
error: function(err){/* There was an error getting location. */},
accuracy: "neighborhood"
});
There is also a lot of talk around privacy and accuracy, and Apple has their own location manager too.
I hope that we can unify some of this, and give the browsers a geo location API soon. One simple JavaScript abstraction will enable a lot of great apps.
Ryan Stewart of Adobe and I got to give a joint talk this morning that covered Adobe AIR, Gears, and how you can build offline and desktop applications right now.
Obviously, Ryan gave an overview of AIR, and I did the same for Gears. We also discussed reasons to be excited about Web development, some of the ideas that are out there in the community, and how AIR and Gears can be seen as complementary.
We had some requests to put the slides online, so here they are below. I know it is hard to peruse slides without the talk over, but just think of it as a fun exercise to wonder what we said :)
After posting about Yahoo! BrowserPlus, we certainly have more questions than answers, and we could all wait a week or two to learn more.
But, where is the fun in that? Thanks to the fact that Open Source software often normally means that you will find a LICENSE.txt, and the binary itself will have information on what is used, you can sometimes glean information. Oh, and the UNIX strings command can help too ;)
So, armed with enough data to be dangerous (yet totally wrong) we see that:
The components seem to be called Corelets
There are distribution servers that can serve Corelets. The primary is set to browserplus.yahoo.com, but you could imagine anything.com too
There is the notion of "Dynamic Corelets" which leads you to believe that you can get new ones into the system, or that you can use dynamic languages to program the system.
OpenSSL is packaged and it appears that you use certificates to make sure the right code is run. It is unknown if you are given SSL primitives to work with, which would be fun
A native JSON implementation is bundled, which is probably just to parse the config file, and not exposed to developers
There is the notion of an "Upload Corelet" which could mean a way to upload new ones into the system, or a better file upload (please)
If you look in the installation directory, you also see the NSPR which tells us that the system uses the Netscape Portable Runtime:
The Netscape Portable Runtime, or NSPR, is a platform abstraction library that makes all operating systems it supports appear the same to Mozilla. NSPR provides platform independence for non-GUI operating system facilities. These facilities include threads, thread synchronization, normal file and network I/O, interval timing and calendar time, basic memory management (malloc and free) and shared library linking. A good portion of the library's purpose, and perhaps the primary purpose in the Gromit environment, is to provide the underpinnings of the Java VM, more or less mapping the sys layer that Sun defines for the porting of the Java VM to various platforms. NSPR does go beyond that requirement in some areas and since it is also the platform independent layer for most of the servers produced by Netscape. It is expected and preferred that existing code be restructured and perhaps even rewritten in order to use the NSPR API. It is not a goal to provide a platform for the porting into Netscape of externally developed code.
Ok, not back to just waiting for the real information. Again, it is great to see Yahoo! apparently thinking about how to make browsers do new tricks, which is why I am excited about Gears.
Awhile back I heard a rumour that Yahoo! had a "Gears-like" project that was cancelled. I thought this was a shame, as having Yahoo! pushing the browser would be a great thing, and I wished that we could all join forces and push together.
After 3 years of hiding out in the campuses of Yahoo! it’s good to finally have something external to show for it. Most exciting is the release of BrowserPlus, a software and software distribution framework that allows device developers (desktop, mobile, etc.) to seamlessly bridge the browser programming environment (DHTML, JS) to any component they can dream up (VoIP, image manipulation, data caching, etc.). Some time ago we created a platform team to focus on device software at Yahoo! and this is what has emerged amidst the quickly shifting strategy of the mothership. The 1.0 release of BrowserPlus is intended only for use by Yahoo! sites to enhance customer experiences; however, in the coming months, developers might expect the ability to use components on their own sites.
In the meantime, you can hack the framework on your own system after you’ve installed it to start experimenting. You can experience BrowserPlus currently through the PhotoDropper module on Mash, though direct installs are available for mac or pc
There isn't a lot of information out there, but hopefully we will here more soon. It currently doesn't seem to be open source, but I would love to reach out to the team, and Yahoo! in general. I consider Yahoo! a proponent of the Open Web, and would love to see us work together in a way that pushes the browser platform forward from the point of view of Web developers (as compared to browser vendors).
It would be great to take the PhotoDropper, and make the generic kick arse file uploader (input type="file" multiple="true") that I have wanted for a long time.
Malte has continued to work on Joose, his meta object system for JavaScript. He has added a lot of documentation, including cookbooks that tell the story nicely. He also told us about a feature that is near and dear to my Google heart:
Joose now includes a simple object relational mapper for the Gears database in the examples section. If you have Gears installed, you can run it.
It will run its test suite and then display a class browser that displays the contents of a table for classes that represent a database
tables. The example has two entities (Car and Person in the MyEntities module).
Declaring the entities with this proof-of-concept OR-mapper looks like
this:
, GWT
