Re: [whatwg] autobuffer on new Audio objects
2009/7/31 Ian Hickson i...@hixie.ch:
On Mon, 20 Jul 2009, David Wilson wrote:
2009/7/19 Ian Hickson i...@hixie.ch:
On Mon, 6 Jul 2009, Robert O'Callahan wrote:
When script creates an audio element using the new Audio constructor,
the 'autobuffer' attribute should be automatically set on that element.
Presumably scripts will only create audio elements that they actually
intend to play.
Done.
This seems like surprising behaviour (and a nasty asymmetry between
markup and JS): for the savings of a single line of code, creating a
new element will automatically result in (high bandwidth) network IO.
Only if the user agent honours the autobuffer attribute. It doesn't have
to.
I still don't understand the 'why' of this, whereas the 'why not'
seems clear. It might be useful (in a saving an extra line of code
kind of way), but the fact it implicitly causes potentially high
bandwidth IO seems more wasteful than convenient.
What about adding an autobuffer parameter to the constructor which
defaults to false?
I don't think the intent of creating Audio instances clearly always
means playback will happen.
What other use cases do you have in mind?
The playlist example given doesn't seem that unreasonable, it's
something an unsuspecting developer might do in a hurry.
It's a good idea to make types as general as possible, particularly
for browsers where libraries like jQuery make it convenient to treat
DOM nodes as data structures. Forcing a user to type extra
(document.createElement('audio')) in order to avoid surprising
functionality doesn't seem right.
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).
A mobile phone would not autobuffer in a background tab
3G doesn't mean mobile phone. I barely use my phone's browser, but use
net via Bluetooth all the time, various Dell laptops come with 3G
available as an option built in, for many in Africa its the only
available network, etc.
David
--
Reality is that which, when you stop believing in it, doesn't go away.
— Philip K. Dick
Re: [whatwg] autobuffer on new Audio objects
2009/7/19 Ian Hickson i...@hixie.ch: On Mon, 6 Jul 2009, Robert O'Callahan wrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Done. This seems like surprising behaviour (and a nasty asymmetry between markup and JS): for the savings of a single line of code, creating a new element will automatically result in (high bandwidth) network IO. I don't think the intent of creating Audio instances clearly always means playback will happen. 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). David On Sun, 5 Jul 2009, Adam Shannon wrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. On Mon, 6 Jul 2009, Robert O'Callahan wrote: What about them? I'm not sure what your point is. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. On Sun, 5 Jul 2009, Adam Shannon wrote: There already low bandwidth would be crippled more than it already is. (By loading audio files. I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... On Mon, 6 Jul 2009, Robert O'Callahan wrote: For in-page audio, put an audio element in the page. Robert is right; inline audio handles this fine, and is distinct from new Audio(). -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Reality is that which, when you stop believing in it, doesn't go away. — Philip K. Dick
Re: [whatwg] hash sum tags of binary files and code blocks?
2009/7/13 Christian Nygaard christiannyga...@gmail.com: What if one included hash sums of every binary file in html tags, plus embedded hash sums in streaming file blocks, then the client would never need to look at time stamps/expire headers to determine if it could cache the objects. That would make caching very easy on mobile devices with slow datalinks, make it possible for service providers to cache objects globally for their customer base. One could also augment whole code blocks with hash sums for example css this could possibly be more efficient than time expire. img src=example.jpg md5=f2bd08fae5adb96c9befa02bddb4a90c How would this interact with HTTP Accept header? It seems each resource would be required to have only a single presentation, and that the HTML was intimately aware of the details of that presentation, or alternatively intimately aware of what presentation the user agent would request. hash md5=bda497e29a81a038208ab94101e2e793 skipaheadlines=10 style /style /hash link rel=stylesheet type=text/css href=external-style-sheet-file.css md5=dee0b8572297fe4e3b004cfe188ecad3/ no need to load that style sheet ever again if it's contents has not changed. This scheme doesn't really fit HTTP at all. However that's not to say it's interesting. In fact swathes of research have been devoted to designing access layers like this (they're often called content addressable networks). Introducing little bits of it into HTML seems like the wrong layer to be working on. David -- Reality is that which, when you stop believing in it, doesn't go away. — Philip K. Dick
