[whatwg] Installed Apps
ian at hixie.ch
Thu Aug 13 04:07:45 PDT 2009
On Tue, 4 Aug 2009, Drew Wilson wrote:
> On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> > It seems like a direct solution to these would be to have a way for
> > Web pages to expose a service that clients could subscribe to, which
> > could send up database updates and notifications. That way, no script
> > runs on the client, but the server can still update the client
> > whenever needed.
> Yeah, this is an interesting idea, although I'm envisioning apps that
> support offline use requiring what amounts to a sync process with
> app-specific conflict resolution, etc - I think this would be difficult
> to support with this kind of general platform. But, agreed, this is
> better than nothing - at the very least, an application could use it to
> sync down changes to a "staging area" for later resolution once the app
> itself starts up.
Ok. I think this is the direction we should look in to address this use
case then. I haven't specced anything yet, but I've noted it as a feature
we should look at. If anyone wants to experiment in this space, that would
> Sure, although I'd say that "persistent storage is addressed by the Web
> Storage and Web Database features". Shared state is also addressed, but
> that's not the primary goal. If I have a tree of objects that I'd like
> to share between two pages, telling me to serialize it into name/value
> string pairs, write it into Web Storage, and then have the remote side
> read it out is not a satisfying (or performant) solution.
Web Storage supports structured data now.
> Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to
> notifications (our vision for notifications is that they are scriptable
> and more interactive than just a dumb text + icon).
A system that displays rich/scripted content on server demand rather than
on user demand is a massive security nightmare. It turns a scripting
security bug and an XSS bug into an instant malware deployment vector.
> Additionally, any server-side-feed-based solution has the implication
> that it won't work for offline apps. If I am using a web calendar, I
> want my event notifications regardless of whether I'm online or offline
> (the event may have been added while I'm offline and never synced to the
> server at all).
I think on the long term we may wish to consider adding a feature to queue
up POSTs for when the UA finds it is back online. That would address a
number of problems, including this one.
On Tue, 4 Aug 2009, Jeremy Orlow wrote:
> The idea of tying the notification spec to a particular brand of storage
> seems like a bad idea...especially at this point in time.
We can make this work with all of the mechanisms pretty easily.
> On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I'm not sure XMPP is the protocol I would jump to, but it's certainly
> > an option, yes.
> What don't you like about XMPP?
It's far too complex for people to write and deploy an XMPP server on a
whim. Like HTTP, it requires people to use off-the-shelf software instead
of allowing them to experiment with their own code. This leads to software
monocultures, and prevents easy experimentation.
On Tue, 4 Aug 2009, Dmitry Titov wrote:
> What about the "shared context with DOM access" idea which, even w/o
> persistency, seems to resolve some issues for apps like GMail? Like a
> shared worker, but with access to DOM.
I don't think that such a mechanism will work well given multicore
processors, multiprocess UAs, and the way that gadgets end up connecting
domains all over the place.
> 2. It does rely on 'cooperative' pages to be opened in the same process
> but this is easy to implement. I mean, you can't 'guarantee' it (a page
> from another domain may have iframe pointing to the app and it will be
> in a diff. process) but any reasonable app can be easily structured in a
> way to get its views (pages) into a single process.
I think this is understating the disadvantages of this model, and
overestimating the ease with which one can make it work.
> 3. It would help to provide fast (meaning sub-100ms, interactively fast)
> UI responses necessary for the seamless operations. Persistent data
> storage and parsing/generating HTML (including loading all the code
> necessary to do that from the 'pure data') will always present challenge
> for sub-100ms UI actions - even in native apps it is a challenge today.
> Here is a typical use case: You compose a message in GMial window.
> Halfway through you decide to peek into another mail thread for more
> information. You click 'tear-off' button to "disconnect" the compose
> window so you can see other mail threads. Today, this opens a new window
> and starts loading XXX Kb of script into it. You see the progress
> indicator for a few seconds. This script is needed to be able to go to
> server and generate a proper UI from the response, as well as have all
> the 'controller' logic when user starts to interact with such UI.
> With shared context, you could just take the whole DOM subtree that
> forms a compose window UI and pass it, as is, into the new and empty
> window - with even handlers hooked into the shared context. It will just
> relayout and continue function. You have an 'instant' tear-off.
You don't need a shared context to do this. window.open() gives you the
DOM, you can already populate it immediately.
On Sat, 8 Aug 2009, Drew Wilson wrote:
> One of the reasons I'm a proponent of running application script is the
> track record of one-size-fits-all, generic push solutions that are able
> to fulfill a broad range of use cases is fairly poor. If we are going to
> have the browser manage an incoming feed of push notifications, then I'd
> say at the very least we should allow web apps to register script
> handlers for those notifications, rather than try to build in static
> browser behavior. One could put limits on the execution of this script
> (perhaps only allow it to run for a limited period of time, for
> example), and provide UX to the end user such that there is transparency
> about the script running in the background of their browser.
I really don't feel right allowing script to run like that.
Why can't the server send the data to the client in a near-final form and
let the script figure it out when the user finally opens the app?
> I agree that the UX and Security issues around always-on persistent
> script are formidable, but I still think it's valuable to experiment in
> this area to see whether they can be overcome.
Certainly experimentation is always encouraged.
> Regardless, I think it's premature to latch onto a single potential use
> case for persistent script (static text + icon calendar notifications)
> and start building extensive alternative mechanisms to satisfy that
What other use cases are there? Those were the ones given. We're very much
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg