On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <i...@hixie.ch> wrote: > For example, we could base this on the EventSource mechanism or the > WebSocket mechanism, and define a protocol by which the server can at any > time send up either: > > An INSERT, UPDATE, or DELETE SQL statement > A string and a URL to show in a notification
The idea of tying the notification spec to a particular brand of storage seems like a bad idea...especially at this point in time. 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. On Tue, Aug 4, 2009 at 9:48 AM, Drew Wilson <atwil...@google.com> wrote: > > On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <i...@hixie.ch> wrote: > >> >> I don't understand why workers can't reduce latency. What is the latency >> that must be reduced which workers can't help with? >> > > 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. > 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. 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. > > >> >> > SharedWorkers are overloaded to provide a way for pages under the same >> > domain to share state, but this seems like an orthogonal goal to >> > "parallel execution" and I suspect that we may have ended up with a >> > cleaner solution had we decided to address the "shared state" issue via >> > a separate mechanism. >> >> Shared state is addressed by the Web Storage and Web Database features; >> the shared workers are intended to provide shared computation. >> >> > 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. > 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. > 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). > 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. On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <i...@hixie.ch> wrote: > > On Thu, 30 Jul 2009, Michael Davidson wrote: > > > > Here's a rough sketch of a more far-out idea: What if all browsers were > > XMPP clients and stanzas could be sent to display notifications? The > > attack surface would still be low, but you'd get realtime updates. > > Instead of subscribing to a feed of notifications, the user accepts what > > is essentially a chat invitation from the site. Like normal XMPP > > invitations, this would be revocable at any time. > > 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?
