<br><div class="gmail_quote">On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> Sure, although I'd say that "persistent storage is addressed by the Web<br>
> Storage and Web Database features". Shared state is also addressed, but<br>
> that's not the primary goal. If I have a tree of objects that I'd like<br>
> to share between two pages, telling me to serialize it into name/value<br>
> string pairs, write it into Web Storage, and then have the remote side<br>
> read it out is not a satisfying (or performant) solution.<br>
<br>
Web Storage supports structured data now.<br>
</blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A system that displays rich/scripted content on server demand rather than<br>
on user demand is a massive security nightmare. It turns a scripting<br>
security bug and an XSS bug into an instant malware deployment vector.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> Additionally, any server-side-feed-based solution has the implication<br>
> that it won't work for offline apps. If I am using a web calendar, I<br>
> want my event notifications regardless of whether I'm online or offline<br>
> (the event may have been added while I'm offline and never synced to the<br>
> server at all).<br>
<br>
I think on the long term we may wish to consider adding a feature to queue<br>
up POSTs for when the UA finds it is back online. That would address a<br>
number of problems, including this one.<br>
</blockquote><div><br></div><div>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:</div>
<div><br></div><div>1) A server-controlled push notification stream, as well as infrastructure for applications to insert/remove notifications into the stream for offline use.</div><div>2) Some kind of server database push-sync protocol.</div>
<div>3) Some kind of "queued up posts" feature (with assumedly yet more infrastructure to deal with errors/return values from these delayed POSTs).</div><div><br></div><div>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.</div>
<div> </div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I really don't feel right allowing script to run like that.<br>
<br>
Why can't the server send the data to the client in a near-final form and<br>
let the script figure it out when the user finally opens the app?<br>
<div class="im"></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div>What other use cases are there? Those were the ones given. We're very much<br>
use-case-driven here.<br>
<font color="#888888"></font></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>