- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 3 Feb 2014 20:29:59 +0000 (UTC)
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Mon, 3 Feb 2014, Jonas Sicking wrote: > > I agree that being able to prevent an object from getting GCed isn't > great, however any solution in this space is going to require the UA to > retain a bit more memory. The reason that we need to retain the > MessagePort object in the solutions discussed so far is that we've tried > to fire the event on the MessagePort object itself. If we instead fired > an event on the global indicating "the other side has gone away", then a > MessagePort doesn't need to be retained. > > However such a solution requires a different way to identify which > communication channel was severed. We could allow naming ports and then > the name of the port would be included in the "lost connection to an > other side". Of course, that requires keeping that name in memory which > is arguably as leaky. Or we could come up with numeric port identifiers, > in which case less memory is "leaked". I think this would just result in authors keeping track of the ports in an index, which would prevent them from being GC'ed, which defeats the point. > The bfcache issue is solvable as discussed. > [...] > As soon as any of them can't deal with bfcache the page won't be > bfcached. I don't think "solvable" is the same as "design an API that basically guarantees that within a decade most of the Web won't be bfcached". > I'm happy to experiment. In the meantime I would ask that > MessagePort.onerror is removed as I don't think any browser vendor has > expressed a desire to implement. Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 3 February 2014 20:30:22 UTC