[whatwg] autobuffer on "new Audio" objects

[Philip Jägenstedt]

On Mon, 20 Jul 2009 07:06:32 +0200, Nils Dagsson Moskopp  
<nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:

> Am Montag, den 20.07.2009, 05:46 +0100 schrieb David Wilson:
>> It's easy to see how some naively implemented JS audio widget could
>> fetch 200mb over an expensive 3G connection, simply by navigating to
>> some site in a background tab (say, by creating an array of elements
>> to represent their playlist - something I'd have thought was perfectly
>> valid behaviour).
>
> I second that motion, not only as owner of a smartphone, but also as
> someone with webspace that has a volume cap. Automagic audio element
> buffering could deter web authors from dynamically putting more than one
> element on a page, thus reserving javascript playlist widgets to those
> who can afford more bandwith on an order of magnitude (!).
>
> I believe the burden of writing another line should solely be on those
> who want autobuffering, to prevent unneccessary bandwith consumption.
>
> Cheers

Regardless of whether the spec mandates that the autobuffering attribute  
be set for new Audio(), browsers that want to be competitive on mobile  
will have to be conservative with bandwidth. autobuffering is only a hint  
and doesn't need to be obeyed where it doesn't make sense (in fact can't  
be obeyed because the disk cache is too small).

-- 
Philip Jägenstedt
Core Developer
Opera Software