<div class="gmail_quote">2009/7/29 Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello folks -<br>
<br>
I'm an engineer on the Gmail team. We've been working on a prototype<br>
with the Chrome team to make the Gmail experience better. We thought<br>
we'd throw out our ideas to the list to get some feedback.<br>
<br>
THE PROBLEM<br>
<br>
We would like to enable rich internet applications to achieve feature<br>
parity with desktop applications. I will use Gmail and Outlook as<br>
examples for stating the problems we hope to solve.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Slow startup: When a user navigates to <a href="http://mail.google.com" target="_blank">mail.google.com</a>, multiple<br>
server requests are required to render the page. The Javascript is<br>
cacheable, but personal data (e.g. the list of emails to show) is not.<br>
New releases of Gmail that require JS downloads are even slower to<br>
load.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Native apps like Outlook can (and do) run background processes on<br>
the user's machine to make sure that data is always up-to-date.<br>
-- Notifications: Likewise, Outlook can notify users (via a background<br>
process) when new mail comes in even if it's not running.<br>
</blockquote>
<br></div>
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.<br>

</blockquote><div><br></div><div>Depends on the device. If you're on Android (or I suspect iPhone, although I don't have one), doesn't the device sync your email constantly in the background? If I am a web-based email provider, I would like to have a similar option. Especially on something like the iPhone or Android, where I don't think it's reasonable to expect them to keep the browser open all the time (as the browser will just get closed if some other active app applies memory pressure).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
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.<br>
<br>
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:<br>

<br>
* Notification Feeds *<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
</blockquote><div><br></div><div>It addresses some use cases (calendar, perhaps), but I would still like to be able to e.g. keep my email up to date. Do I need the "full power" / "fully general" solution? I don't know, perhaps the push mechanism can be structured in a way that it gets into my database or whatever storage mechanism I am using for offline data storage?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
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.<br>

<br>
<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br>