- From: <bugzilla@jessica.w3.org>
- Date: Mon, 28 Nov 2011 22:32:58 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399
Max Kanat-Alexander <mkanat@bugzilla.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mkanat@bugzilla.org
--- Comment #31 from Max Kanat-Alexander <mkanat@bugzilla.org> 2011-11-28 22:32:53 UTC ---
(In reply to comment #30)
> I'm saying there should be a network protocol that does this, yes.
Oh. It couldn't all be just a network protocol, though, because a lot of the
decisions have to be made on the client--only the client can know if it's able
to play back a format well-enough.
Also, are you thinking this would be something on top of HTTP? Inserting
other protocols than HTTP is going to make life difficult for client-side
developers.
> I don't see why it would freeze anything in time.
There's always going to be some browser somewhere that can't be updated (or
which updates slowly--for example, most mobile browsers today) which the
server-side will have to support.
> I don't see why browser vendors and server vendors can't innovate also.
They can! And I agree that they should, and I agree that for most developers,
having this built into the browser is absolutely the best solution. My point is
that JS developers can push out new code from day to day, while it can take
months or years for a new browser to have sufficient usage.
> I would recommend filing separate bugs for other use
> cases, though, rather than having all metrics-related use cases dealt with in
> one bug. I'm sure that if you ask the chairs they'd be happy to handle such
> split-out bugs as LC1 also, if that matters.
I think that sounds totally reasonable. I'll file a separate bug for the
playback-quality stuff.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 28 November 2011 22:33:00 UTC