- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 13 Aug 2009 11:07:45 +0000 (UTC)
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