On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking <jo...@sicking.cc> wrote: > > On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell <slightly...@google.com> > wrote: > >> One solution would be to at that point allow the SW from the other > >> origin to install itself, which means that you can then just talk to > >> it as a normal installed SW. However installing a SW could take > >> significant amount of time. On the order of tens of seconds if the > >> user is on a slow connection and the SW represent an app with heavy > >> resources. > > > > I'm OK with it taking time. The discovery phase of a n.c() setup is > async. > > This is along time though.
I don't imagine these are the same SW's as the main app in the common case. As a result, these can (should?) be custom built, be lighter, and perhaps can communicate with the main app SW (if it's installed). Manually visiting these URLs seems, to me, to be about viewing an admin page for a service endpoint. So yes, install is at least one network RTT (probably several), but I'm not sure that's fatal. At least you can communicate what's going on (to the extent that you have UI up and running). > If the initiating website is holding *any* > UX before getting a response you'll end up with a unreasonably bad > experience. I think this is a good reason not to transparently tie this to fetch(). > So for example if cross-site communication is initiated > when the user press a button, the response to that button push can > take unacceptably long. > This is, perhaps, a good reason for a discovery system; one layered on top of direct point-to-point RPC. It'd be _nice_ to know if you have a local handler for some sort of service before you go calling it. The privacy implications are pretty thorny, though, so we haven't proposed it. > It also means that we couldn't use SW for WebActivities/WebIntents for > example. That seems unfortunate. > I don't follow. > I don't feel like we're heading down the right design. > > / Jonas > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
