Re: revised recording proposal

Mandyam, Giridhar wrote:
> Thanks - this is along the lines of what I would have liked to point out
> regarding implementations of typed arrays versus blobs (but not quite
> everything).  I don't believe this distinction is irrelevant at all.  But I

Can you explain why you believe it is relevant? The Blob case, I should 
point out, is actually the "normal DOM object" case. I.e., it's actually 
ArrayBuffer which is special, but not in any way that I can see is 
significant.

> can also understand why going into the topic of specific implementations can
> be problematic in this group.

I can't. We're talking plumbing here. This is not rocket science. If we 
can't even discuss this stuff, we might as well forget talking about 
anything that's actually valuable.

> I think one goal should be to avoid replication of multimedia buffers in
 > virtual space due to multiple references.

I agree, which is why, as Jim points out elsewhere, the immutability of 
Blobs is important. Without that, the UA has to copy the data every time 
it hands it to any listener, to prevent them from tromping on the 
underlying data that someone else might be using.

> Blobs could (and should) be implemented in a similar fashion I suppose, but
>  [snip]
> conceivable that the new blob created from a slice could result in a new copy
> in a poorly designed UA - there is no normative text preventing it.

Normative text is for ensuring interoperability, not mandating minor 
performance optimizations (UAs have plenty of incentive to enable those 
regardless of any normative text). But I think this has gone pretty far 
into the weeds. If you have an implementation and associated benchmarks 
that demonstrate one approach performs much better than the other, than 
that is interesting. Otherwise, not so much.

If we want to discuss esoteric implementation details: In Gecko 
ArrayBuffers have a 4 GB limit (and any 32-bit UA will have a much 
smaller one). This is a limit that in practice it is quite common to hit 
while doing whole-file-at-once recording.

Received on Thursday, 29 November 2012 20:55:22 UTC