[whatwg] Installed Apps

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


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

What other use cases are there? Those were the ones given. We're very much 
use-case-driven here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 13 August 2009 04:07:45 UTC