- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Mon, 03 Mar 2014 09:21:50 -0500
- To: public-webrtc@w3.org
On 3/3/2014 9:13 AM, Harald Alvestrand wrote: > On 03/03/2014 02:06 PM, Martin Thomson wrote: >> On 3 March 2014 04:18, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote: >>> I still think that's strange API behavior. >> I don't see any strangeness here. If I have a reference, then the >> object is not garbage collected. If not, then not. >> > Do we currently close a datachannel if it's garbage collected (that is, > if the app loses all references to it)? > Or do we let it sit idle until the PC is garbage collected? Absolutely it can be GC'd per the spec. > (section 5.4 of the spec seems to allow us to garbage collect it if > there are no handlers registered, but doesn't explicitly say that it > closes when garbage collected). It would be useful to add a sentence to say it's closed if it's GC'd. > If we introduce a getter, people have a reasonable expectation that the > channel should stick around until closed, even if they have not bothered > to add event handlers to it yet. You have a point, in that we usually try to avoid users knowing about GC - but we've already broken that for WebSockets and DataChannels. I'll restate my comment from my response to this issue: [ I don't have a problem with doing this, but: ] The strongest argument against is that the functionality is already (as you say) implementable in userspace for those who need it without major trouble. -- Randell Jesup -- rjesup a t mozilla d o t com
Received on Monday, 3 March 2014 14:23:42 UTC