On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote:
Hello folks -
I'm an engineer on the Gmail team. We've been working on a prototype
with the Chrome team to make the Gmail experience better. We thought
we'd throw out our ideas to the list to get some feedback.
THE PROBLEM
We would like to enable rich internet applications to achieve feature
parity with desktop applications. I will use Gmail and Outlook as
examples for stating the problems we hope to solve.
I already commented on the security risks of the proposed solution,
but I'd also like to examine the use cases more closely. "Feature
parity with desktop applications" is pretty open-ended, and it might
be that the actual concrete use cases can be addressed with less
general mechanisms.
-- Slow startup: When a user navigates to mail.google.com, multiple
server requests are required to render the page. The Javascript is
cacheable, but personal data (e.g. the list of emails to show) is not.
New releases of Gmail that require JS downloads are even slower to
load.
Caching the code part of GMail, and making loading fast in the face of
updates, seems like a problem that can be solved by the HTML5
Application Cache. Maybe it would be more fruitful to study further
improvements in startup speed once GMail has adopted AppCache.
-- Native apps like Outlook can (and do) run background processes on
the user's machine to make sure that data is always up-to-date.
-- Notifications: Likewise, Outlook can notify users (via a background
process) when new mail comes in even if it's not running.
I'm not sure it's justifiable to say these features are required for a
native-like experience. The Mail application on Mac OS X only fetches
new mail and gives you new mail notifications while it is actually
running. Users who want to know about new mail right away keep the app
open, and users who would like to free up resources quit it. It seems
like GMail can already get rough parity with this experience.
That being said, I think there are valid use cases for out-of-band
notifications, for example for calendar events or "status update" type
applications such as Facebook or Twitter.
I'd like to explore whether we can accommodate this notification use
case without bringing the full power of the Web platform to bear, and
thereby opening up a lot of attack surface on the client. Here's one
rough sketch of an idea:
* Notification Feeds *
Often, web applications would like to give users the option to
subscribe to notifications that occur at specific times or in response
to server-side events, and for the user to get these UI notifications
without a prerequisite that the web app is open or that the browser is
running. There may be a desire to do client-side computation as well,
but often just the ability to give the user a notification solves the
basic user interaction problem.
One possible way to address this kind of use case is to let users
subscribe to a "feed" of notifications. This feed could use standard
syndication formats, such as RSS or Atom. But instead of being
displayed in a traditional feed reader, it's displayed in the form of
transient notifications (along the lines of Growl on Mac OS X) which
are posted for each new event. To allow some pre-scheduling of events,
each item can have a date and won't be displayed until that date -
this way a calendar can give you your feed of upcoming events and you
can still get notifications when offline. In the case of something
like email or Twitter, obviously there's no sensible way to get
notifications when offline since they depend on unpredeictable server-
side activity. There could even be a client-side API that lets a Web
app schedule items on a subscribed notification feed from script, to
enable scheduling calendar events offline. Each notification would
have the option to unsubscribe from the notification feed, to reduce
spam potential.
Notice that this opens up a lot less attack surface. The user has to
actively opt in to subscribing to the notification feed, just as for
an RSS feed. This makes it much less likely they end up with a
subscription to a shady site. And the notifications are passive data
items (probably no script should be allowed in a notification, if the
format is HTML and not just plain text), so they open up a lot less
security risk. Obviously this is less powerful than the ability to run
arbitrary code in the background. But it could address a large chunk
of the use cases with much less security risk.
I'd like us to think along these kinds of lines when expanding the web
platform. Often there is a low-power alternative to fully general
solutions, which addresses many of the same use cases. By proceeding
in this manner, we can extend the power of the web platform without
neutering its desirable security properties.
Regards,
Maciej
