[whatwg] Installed Apps

[Drew Wilson]

On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson <ian at hixie.ch> wrote:

>
> > 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, the fact that the UA will automatically jsonify my (cycle-free) data
structures does not really make this a great solution, for many of the
reasons Mike Wilson mentioned. That said, once you've architected your
application around having only asynchronous access to your data structures,
there are lots of tools available in HTML5 to do sharing (use WebStorage as
you describe, push all data access through a SharedWorker, keep duplicate
copies of data structures in each page and update them via DB or
SharedWorker messages, etc).


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


Another name for "a system that displays rich/scripted content on server
demand" is "an open web page" :) The only difference is the user has UI to
close a web page when he's done interacting with it, while the UI to
enable/disable notifications from a domain is probably less obvious.

Scriptable notifications are a use case that none of these proposals
currently satisfy. I understand the security concerns. I just don't (yet :)
share the general belief that they are insurmountable which is why I want to
continue experimenting in this area.



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

I'll just note that to get a narrow subset of the behavior that simple
background scripting would provide (static notifications and static data
synchronization without client-side reconciliation), we're having to have:

1) A server-controlled push notification stream, as well as infrastructure
for applications to insert/remove notifications into the stream for offline
use.
2) Some kind of server database push-sync protocol.
3) Some kind of "queued up posts" feature (with assumedly yet more
infrastructure to deal with errors/return values from these delayed POSTs).

What you really want for #2/#3 is a general-purpose sync protocol, but I
don't see how you do it without some form of client-side conflict
resolution.

I hope that people understand why application scripting seems like a more
attractive, general-purpose solution. I'm unable to muster much enthusiasm
for a set of convoluted server-and-client-side mechanisms that cover such a
narrow set of use cases without any way for client applications to customize
this behavior through scripting.


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

What if there are things the application wants to do to act upon this data
immediately (add items to the notification stream, for example)? What you're
saying is we need to push all of this functionality up to the server, then
provide a very narrow set of APIs (essentially, static notifications) that
the server can use to act on that functionality.


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

I won't claim to understand all of the potential use cases yet, but I have a
preference for general-purpose solutions rather than solutions that narrowly
target a set of specific use cases, although I recognize that more
general-purpose solutions have commensurate security implications.

I'd like to just experiment with background scripting/scriptable
notifications in a way that people find acceptable (either without
persistence, or using extensions for persistence), see how applications
actually use them, then continue this conversation. People are certainly
welcome to do parallel experimentation with other approaches such as the
ones you've outlined above.


>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090813/5ba1d9dc/attachment-0001.htm>