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:
Back to Aaron's post which I couldn't say any better, so I put here for ease of browsing:
Gears is about more than just offline web applications. For example, we recently added desktop shortcut functionality, and we're working on resumable uploads, a geolocation API, and lots more fun things for the future.
We've received some questions recently about how all this relates to web standards, such as HTML5 and those proposed by the W3C. It seems like some people are afraid Gears will try to compete with the web.
Let us put those fears to rest right now: on the Gears team we loves us some web standards. Some of us were web developers stuck in the crossfire of the browser wars, and we deeply understand standards have played a key role in the productivity and creativity of the web over the past 10 years.
We have no desire to create a parallel platform and compete with the web. Anyway, that would be crazy. The web is an unstoppable force of nature. Competing with it would be like entering a shouting match with the wind: you can't win, and you look pretty silly trying.
Instead, Gears aims to bring emerging web standards to as many devices as possible, as quickly as possible.
Some History
The Gears project started because a group of developers at Google were frustrated by the slow march of web browsers. Competition and standards were producing fantastic results, but it took a long time to get implementations on every browser. In some cases, we still don't have compatible implementations, years after the standards were finalized. Our first project was to implement APIs that would make offline web applications possible.
Currently, the Gears Database and LocalServer modules are not fully compatible with the HTML5 proposals for the same functionality. This is only because those specs were written after Gears was released, and not because of any desire to be different. In fact, we were involved in the design of both HTML5 specs, and we are currently implementing the proposal for database access.
Going Forward
In many ways, Gears is like a browser without any UI. And just like other browsers, Gears will implement existing standards and rally for changes and additions where they seem needed. For example, we recently proposed our geolocation API work to the W3C WebAPI group.
There are three important differences between Gears and other browsers, however:
Improvements to Gears can be used by developers immediately. Gears is available today on Firefox (for Windows, OS X, and Linux), IE, and IE Mobile. Implementations for more browsers and platforms are in progress. Developers no longer have to wait for every browser to implement new web standards before they can use them, they only have to wait for them to be available on Gears.
Most browser vendors have two groups of customers: users and developers. User-facing features typically get more attention than developer-facing APIs, for a variety of reasons. But with Gears, developers are the only customers. We can focus completely on creating the best possible platform for web development.
Gears is an implementation of web standards that lives inside another browser. For example, the HTML5 Database API might be available to developers through both the google.gears object and the traditional window object. This is OK, and in some ways a good thing. Developers will be able to mix and match the pieces of Gears and native browser implementations that work best.
The Pitch
By implementing emerging web standards, Gears is influencing what the web of tomorrow will look and act like. And since Gears is an open source project, anyone can contribute.
Get involved. You don't have to be able to code in C++. All that's needed is some free time and the desire to push the web forward.
Being able to have your documents stored up in the cloud, but also saved away for the time where you don't have connectivity is important, and today the Google Docs team supports local service via Google Gears.
I have been using this ability for awhile, and I have personally seen a couple of side effects:
I boot up the computer at times in which I wouldn't before hand as I know I can get access to this content (as well as Google Reader of course)
The experience is a lot faster even in a connected or slightly connected environment as it keeps working even if service is bumpy, say, on a Google Shuttle to work!
Having things continue to just work as you go in and out of service is a great feeling. You trust the system more.
We want to applaud the IE 8 team for the work that they have done, but also keep pushing to make sure that it really happens:
I was reminded of a discussion last Friday where I voiced my frustration that as much as IE 8 looks to be a good point release, we know next to nothing about it’s intentions with regards to ship dates or auto-update deployment. I’m not talking exact dates or firm plans here, just “within the next N months” or “we’ll wait N (plus or minus 3) months to put it on Windows Update”. Knowing those things fill in the missing bits of making any plans around IE. No plan is complete without a “who”, a “how”, and a “when”. Right now we’ve got the first two bits (ish), but the third is a mystery….which means we don’t have a collective plan.
By the transitive property of IE being the monopoly market-share browser, we can clearly state that we have no idea when the Open Web will be revved. This is based solely on the IE team’s lack of commitments. This is a terrible result, and one which I think the frenzy over IE 8’s features has obscured.
He then talks about the browser platform:
Which brings us back to IE being a platform. The bits that webdevs care about must change in order for the web to get better, and today webdevs are platform customers without a commitment from their biggest supplier to ship another version beyond the one they’re working on now. If this were any other sort of platform, this would never ever fly. Code-in-escrow would be demanded along with a roadmap, or at a minimum a commitment to an N+1 version in a reasonable time frame. But webdevs don’t have that leverage by virtue of the disintermediation that browser economics now demand.
So as webdevs, we must be canny enough to find a way to “better” which doesn’t put all of our eggs in any particular basket. Every browser that we depend on either needs an open development process or it needs to have a public plan for N+1. The goal is to ensure that the market knows that there is momentum and a vehicle+timeline for progress. When that’s not possible or available, it becomes incumbent on us to support alternate schemes to rev the web faster.
And, how all web developers can push forward with projects like Gears:
Google Gears is our best hope for this right now, and at the same time as we’re encouraging browser venders to do the right thing, we should also be championing the small, brave Open Source team that is bringing us a viable Plan B. Every webdev should be building Gear-specific features into their app today, not because Gears is the only way to get something in an app, but because in lieu of a real roadmap from Microsoft, Gears is our best chance at getting great things into the fabric of the web faster. If the IE team doesn’t produce a roadmap, we’ll be staring down a long flush-out cycle to replace it with other browsers. The genius of Gears is that it can augment existing browsers instead of replacing them wholesale. Gears targets the platform/product split and gives us a platform story even when we’re neglected by the browser vendors.
Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.
At this point in the webs evolution, I’m glad to see browser vendors competing and I still feel like that’s our best long-term hope. But we’ve been left at the altar before, and the IE team isn’t giving us lots of reasons to trust them as platform vendors (not as product vendors). For once, we have an open, viable Plan B.
, Gears
