<div>On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div>For example, we could base this on the EventSource mechanism or the</div>WebSocket mechanism, and define a protocol by which the server can at any<br>time send up either:<br><br> An INSERT, UPDATE, or DELETE SQL statement<br>
A string and a URL to show in a notification</blockquote><div><br></div><div>The idea of tying the notification spec to a particular brand of storage seems like a bad idea...especially at this point in time.</div><div><br>
</div><div>I definitely like the idea of string based notifications. And I like the idea of having a fairly constrained form of updating state on the machine.</div><div><br></div></div><div><br></div>On Tue, Aug 4, 2009 at 9:48 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div>On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">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">
<div><br></div></blockquote></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't understand why workers can't reduce latency. What is the latency<br>
that must be reduced which workers can't help with?<br>
<div></div></blockquote><div><br></div></div><div>As I understand it, the big problems are 1) loading/parsing/executing N-hundred K of javascript for an app like gmail is slow, 2) initializing application data structures from data that must be sent down from the server (or loaded from the database) is also slow (and by "slow", we may only be talking on the order of hundreds of milliseconds). Workers don't do much for either of these, especially when you are launching a web app for the first time.</div>
</div></blockquote><div><br></div><div>It seems like these are things UAs and Moore's law can address. For example, what if the UA was smart enough to cache compiled JavaScript (obviously with very smart invalidation routines...or even hooked into AppCache!). Sure, it's not easy, but there still seems to be a lot of head-room here.</div>
<div><br></div><div>Also keep in mind that lots of web applicaitons think they're pretty important. Sure, giving gmail .1% of your system memory seems worth it. But how do you draw the line? What if I have 10 apps that want to do this? (Say...the top 10 sites on the internet.) Well, now I've just given up 1% of my ram.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
> SharedWorkers are overloaded to provide a way for pages under the same<br>
> domain to share state, but this seems like an orthogonal goal to<br>
> "parallel execution" and I suspect that we may have ended up with a<br>
> cleaner solution had we decided to address the "shared state" issue via<br>
> a separate mechanism.<br>
<br>
</div>Shared state is addressed by the Web Storage and Web Database features;<br>
the shared workers are intended to provide shared computation.<br>
<div><br>
</div></blockquote><div><br></div></div><div>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.</div>
</div></blockquote><div><br></div><div>Which use case is this related to? If the shared worker is creating UI elements for the page, then composing HTML and sicking it into a div's .innerHTML is actually (sadly) the fastest way to go at the moment. Besides that, I can't think of why you'd have some huge tree of information for the gmail use case.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div></blockquote><div>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).</div>
</div></div></blockquote><div><br></div><div>What if the notification could have embedded links? If you make them too powerful, you'll definitely see spam/ads/phishing/etc showing up in them.</div><div><br></div><div>
<br></div><div>On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div><br></div></blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div>On Thu, 30 Jul 2009, Michael Davidson wrote:<br>><br>> Here's a rough sketch of a more far-out idea: What if all browsers were<br>> XMPP clients and stanzas could be sent to display notifications? The<br>
> attack surface would still be low, but you'd get realtime updates.<br>> Instead of subscribing to a feed of notifications, the user accepts what<br>> is essentially a chat invitation from the site. Like normal XMPP<br>
> invitations, this would be revocable at any time.<br><br></div>I'm not sure XMPP is the protocol I would jump to, but it's certainly an<br>option, yes.</blockquote><div><br></div><div>What don't you like about XMPP?</div>
</div></div>