The next talk is by Aaron Boodman the lead developer on google gears. The outline looks pretty simplistic talk -not the API just the content covered.
Emphasis on lightweight and incremental rather than revolutionary – did not want to change the way you write AJAX apps. You shouldn’t need a new URL to view the disconnected or connected application and it can tolerate connectedness state.
3 modules – LocalServer- capture html, images, etc. – file server that is a specialized cache NOT and APPserver – serves them first from local cache and then checks for validity – this allows for smooth transition
Database – store large amounts of structured data – SQLLite they added/donated FullText search
His example is an offline notepad example called gearpad – interesting question – what does logout mean for an offline AJAX app?
This example is included with the SDK. It implements synchronization and conflict resolution for it’s data. Interesting slide on how to set up a schema and application architecture to handle editing while still handle synchronization issues
How to version a GEARS app
1) Update your server – chnages the manifest
2) Gears autoupdates to the client – they will be using aout od date version until next reboot
3) Update the app – now is the time to update schema
BP related to this
1) try to not break backward compability – version 1 clients can still talk to version 2 server
2) Have a plan for breaking back compat
clients should be able to detect incompatible server and disable themselves, update, the reload – do this before first shipping
3) Implement a schema migration system from the beginning – do in the beginning to avoid pain later and do it often
make it part of testing- gives a lot of testing
Support for searhcing and sorting in multiple languages in the DB
How much space is currently taken
A raft of workerpool improvements
HttpRequest, times, improved error handling, include() allows to use other libraries in the worker pool, cross-domain workers – strict contract between domains
Cool things that come from questions:
There is user management that looks to cookies to see what user is logged on. So multiple users of readers can be on the same machine
WorkerPools spawns a seperate JS engine on a seperate OSThread – no access to the DOM or the UI so it is really only for non visual work. It seems to be for business logic in the MVC model. Pretty darn cool
It is really developed as an open source project at google – you can subscribe to the mailing lists where all dev is discussed, has a wiki with all the design docs, I am not sure what the contribution process is like. They also have a #gears channel on freenode
Changes on server side to make your app gears eneabled – it is mostly about synchronization so that your app can handle going on and offline.
Didn’t start out to enable offline synch – instead was just to make AJAX apps better. For example he wrote an app that could encrypt data on the client but then NOT let the server decrypt. You need to store the key on the client to decrypt again but cookie would not be a good place to store it.
No work on spatially extending SQLLite – though if they did it would be killer. You could cache your Points of interest locally so that maps could be closer. And without being connected you could do sql calls for find points close by – could see this be of value for things like starbucks and other things of that nature.
All done – time for lunch – with the obligate speed geeking. I think API providers are at different developers and now the people get to go around to get them to give a “why I should use their API” 5 minute presentation. Should be fun…