[whatwg] Installed Apps

[Ian Fette (イアンフェッティ)]

2009/7/29 Maciej Stachowiak <mjs at apple.com>

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

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


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


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090730/b29d72a2/attachment.htm>