sorted by: recent | see : popular

Content Tagged with Gears + page

Brad Neuberg has built a very easy to use client side search tool called PubTools Search using Gears. The project is open source and provides a great avenue to share knowledge on Gears itself.

To accompany the code, Brad wrote a detailed article:

Did you know that you can use Gearsto do fast, client-side searching of data, similar to a client-side search engine? Gears bundles Full-Text Search (FTS) abilities right into its local, SQLite database. MySpace, for example, uses this feature with their MySpace Mail application, downloading all of a user's messages for fast, client-side search. Because all of the data is local, you can do nifty things like search over the data in real-time as the user types, something that is much harder if you have to query over the network to a server to do the searching.

Would you like to add the same kind of fast, local searching to your own web page and web applications? This article introduces you to PubTools Search and the Gears features that power it, namely Full-Text Search and Workers. PubTools Search is an open source JavaScript library that drops a client-side search engine right into your page. You configure it with basic HTML plus a list of URLs to index. Once loaded, a search form that uses the local Gears full-text search abilities will appear in your page to quickly and locally search over the documents in real time as a user types into the search field.

Brad sat down with me to discuss the project, some of the best practices, and his use of Dojo.

Reposted from my personal techno.blog

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.

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.

Brian Dunnington has developed Growl for Windows, and with his latest version, he allows you to talk to the system via JavaScript.

You can check out the growl.js library.

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:

PLAIN TEXT

JAVASCRIPT:

1.  
2. Growl.NotificationType someKindOfNotification = new Growl.NotificationType("some kind of notification", true);
3. Growl.register("Website Name", [someKindOfNotification]);
4. Growl.notify(someKindOfNotification, 'Notification from the web', 'this is the description', Growl.Priority.VeryLow, false);
5.  

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"

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 :)

If you are at Web 2.0 Expo, give me a shout on twitter.

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.

It turns out the rumour is true, and even better, the project has survived. Skylar Woodward of Brickhouse talks a little about it on his blog:

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.

Aaron Boodman, co-lead of the Gears team, has written a very thoughtful post on how Gears relates to various Web standards. My analogy was that of a zipper bringing things together:

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:

1. 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.
2. 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.
3. 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.

Alex Russell isn't talking about the N+1 select problem when he references the Joel Spolsky piece on IE 8.

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.

Disclaimer: I work on the Gears team!

Brad Neuberg, a partner of crime on the Gears team, has released an update to Dojo Storage that has it cooking with gas on the new Dojo 1.x codebase:

Dojo Storage makes it possible to store large amounts of data (hundreds or megabytes of K) on the client-side, way beyond the 4K limit of cookies. Developers are given a simple key/value storage abstraction, similar to a hash table. What makes Dojo Storage unique is that it automatically determines the best way to achieve this. If Google Gears, a small open-source plug-in that teaches current browsers new tricks, is present then this will be used for storage; if the browser supports HTML 5 DOM Storage, such as Firefox 2, then this is used; and finally, if none of the others are available, then a hidden Flash applet is used to store the data permanently. There are even Adobe AIR storage providers (thanks to SitePen and Adobe) if you are running in an AIR environment!

Dojo Storage has been around for a few years. However, when Dojo made the big move to the Dojo 1.0 architecture, the Flash and HTML 5 storage providers broke; plus, new versions of Flash and new browsers made the old design inefficient. I have seriously re-factored the Flash storage system to be much faster and simpler and fixed bugs in the HTML 5 and Gears storage systems. There is now a new storage.js profile build that you can grab and include in your page to easily use Dojo Storage with the three main browser storage providers: Gears, HTML 5, and Flash. The new Dojo Storage will come out as part of the Dojo 1.1 release coming soon.

I've created a screen cast demoing the different storage providers in action: