Re: [whatwg] Character encoding of document.open()ed documents
Henri Sivonen wrote: Spec change request: Please change the spec to say that document.open() sets the document's character encoding to UTF-8 +1. UTF-16 is a troublesome encoding for [X]HTML[5] documents and should be consistently discouraged; as a ASCII-non-superset it interacts very poorly with byte interfaces in HTTP and form submissions. No browser will actually try to submit a form as UTF-16 for this reason, but it still causes problems. eg. Firefox misleadingly sets the `_charset_` hack field to 'UTF-16' even though the submission is UTF-8-encoded. even though the parser operates on UTF-16 DOMStrings. The term 'UTF-16' can mean two very different things: either a sequence of 16-bit code units (as in DOMString), or a sequence of bytes which, taken as UTF-16LE or UTF-16BE, represent 16-code units. Unicode's tradition of conflating the meanings of the code unit sequence and the byte sequence has caused much confusion. DOM Level 3 LS made the mistake of saying that because DOMStrings are UTF-16-code-units, XML documents parsed from `LSInput.characterStream`/`StringData` should receive the `encoding` 'UTF-16', as if the parser has done a conversion from UTF-16-bytes to characters, though no such process has actually taken place. Consequently when you serialise a document parsed from a string in DOM Level 3 LS you get an unexpected and unwanted UTF-16 document. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
[whatwg] Typo on Selection API
Hi, There is a typo on selection API name: http://www.whatwg.org/specs/web-apps/current-work/#selection >selection . collapsed(parentNode, offset) >Replaces the selection with an empty one at the given position. >Throws a WRONG_DOCUMENT_ERR exception if the given node is in a different >document. collapsed -> collapse. The typo is only on the description part. It is OK for IDL. Regards. -- morita
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Wed, Mar 31, 2010 at 3:16 PM, Boris Zbarsky wrote:
> On 3/31/10 2:38 AM, Jonas Sicking wrote:
>>
>> I would have expected bufferedAmount to only change as a result of an
>> event being posted to the main event loop. We generally try to avoid
>> "racy" variables since people don't expect them. Consider for example
>>
>> if (ws.bufferedAmount> X) {
>> setUpSomeState();
>> }
>>
>> try {
>> doOtherThings();
>> }
>> finally {
>> if (ws.bufferedAmount> X) {
>> cleanUpState();
>> }
>> }
>>
>> I'd imagine most JS developers to expect the cleanup to always happen
>> if the setup did.
>
> Sure, but do they expect the cleanup to happen if the setup did not if
> doOtherThings tried to send() stuff?
>
> More to the point, is send() allowed to actually send anything when called,
> or does it have to buffer it all until the next time you get to the event
> loop?
I would expect that send() is allowed to start streaming data over the
network as soon as it can, but only update bufferedAmount from the
event loop.
/ Jonas
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On 3/31/10 2:38 AM, Jonas Sicking wrote:
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop. We generally try to avoid
"racy" variables since people don't expect them. Consider for example
if (ws.bufferedAmount> X) {
setUpSomeState();
}
try {
doOtherThings();
}
finally {
if (ws.bufferedAmount> X) {
cleanUpState();
}
}
I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.
Sure, but do they expect the cleanup to happen if the setup did not if
doOtherThings tried to send() stuff?
More to the point, is send() allowed to actually send anything when
called, or does it have to buffer it all until the next time you get to
the event loop?
-Boris
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Tue, Mar 30, 2010 at 11:20 PM, Niklas Beischer wrote:
> On Wed, 31 Mar 2010 09:38:21 +0300, Jonas Sicking wrote:
>
>> On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky wrote:
>>>
>>> On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount> X) {
doStuff();
>>>
>>> Can bufferedAmount not change due to data actually hitting the network
>>> during the execution of this code? As in, will all the someString data
>>> be
>>> buffered immediately after that send() call?
>>
>> I would have expected bufferedAmount to only change as a result of an
>> event being posted to the main event loop.
>
> I'm certainly no EcmaScript expert but now I'm confused. What event would
> that be? There is no 'onsent' event. Would bufferedAmount not change until
> there is an 'onerror' or 'onclosed' event?
No, an event that's internal to the implementation. See how event
queues work as defined by HTML5.
/ Jonas
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer wrote: > On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking wrote: > >> On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote: >>> >>> On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking >>> wrote: On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote: > > On Tue, 23 Mar 2010, Anne van Kesteren wrote: >> >> We (Opera) would prefer this too. I.e. to not impose details of the >> protocol on the API. > > If we're exposing nothing from the protocol, does that mean we > shouldn't > be exposing that the string converts to UTF-8 either? While exposing the fact that strings are sent as UTF-8 does say something about the protocol, I think it's still much more protocol independent than including the message headers. The string has to be serialized in some way, and it seems unlikely that any newly developed protocol in the foreseeable future would use anything other than UTF-8 as serialization. >>> >>> True, but if bufferedAmount does not byte for byte (or character for >>> character) match what is fed to the API, what does a few bytes >>> representing the current overhead matter? IIRC EcmaScript uses UTF-16, >>> which means that serialization will in most cases make the number of >>> actually buffered bytes differ from the number of bytes in the original >>> message buffer. >> >> EcmaScript doesn't do any serialization so I'm not sure what you mean >> here? > > I meant the serialization in the WebSocket. Unless the protocol > implementation keeps track of exactly how its serialized buffer differs from > the original buffer it will not be able to give a correct answer to how much > of the original buffer is left to transfer. > > >>> And just because we currently use UTF-8 for >>> serialization doesn't mean that will always be the case. Thus API users >>> cannot rely on performing their own conversion to UTF-8 just to find out >>> exactly how many characters in their message have been sent. >> >> My point was that using anything but UTF-8 is unlikely. So the >> opposite of what you're saying here. > > So you're saying binary is out of the question? No. At this point I'm confused as to what your point is. Unless you're simply agreeing with the earlier emails in this thread that the fact that we're converting to UTF-8 and use the converted bytes exposes some protocol details. Are you arguing anything other than that? / Jonas
Re: [whatwg] Character encoding of document.open()ed documents
On 3/31/10 10:37 AM, Henri Sivonen wrote: Gecko sets the document's character encoding to UTF-8 and uses UTF-8 to decode the external resource. One more clarifying question Does Gecko use UTF-8, or the encoding of whatever document it was open() got called on? WebKit uses the encoding of the opener. IE8 (both with compat view button pressed and not pressed) sets the document's character encoding to "unicode" and uses UTF-8 to decode the external resource. Opera uses Windows-1252 to decode the external resource. Similar question for IE. None of IE, WebKit or Opera let the meta charset in a document.open()ed document have any effect As in, it doesn't affect how external resources with no encoding labels are handled? Right. OK. -Boris
Re: [whatwg] Workers: What can be done in a worker after call to close()?
I see, thanks for the details!
This makes sense - you let the worker run unrestricted (ports still send
messages, sync API work) until it exits JS code. It is one of two
possibilities I though of as well (run unrestricted while in JS or immediate
termination).
BTW, the current Worker spec and WebKit do not have 'onclose'. I'm curious
if FF plans to keep it. I've tried to find relevant discussion on exact
reasons it was removed but it hides from me...
Dmitry
On Wed, Mar 31, 2010 at 10:03 AM, ben turner wrote:
> Hi,
>
> When implementing the close() function for Firefox we chose to set the
> closing flag and clear pending events only. As the worker script is
> calling close() on itself we figured that the worker should retain
> maximum functionality until it has finished execution (otherwise it
> could just not call close() and rely on some kind of postMessage() and
> terminate() combo). Therefore we do not enforce any timeout for the
> currently executing script and we continue to allow postMessage()
> calls and synchronous XHR to proceed. Since the closing flag is set in
> response to close() the worker is guaranteed to finish as soon as the
> currently running script finishes. We always enforce a timeout for any
> code that runs in response to the close event that gets fired after
> the current script finishes, though.
>
> If the code that calls close() never returns (like the while(1) { }
> example above) then the worker will never finish, as pointed out
> above, but that's no different than having a worker script that
> consists only of a while(1) { } loop and we don't think it's important
> to prevent. If a worker script is written in this way then a
> terminate() call is still a valid solution.
>
> Also, since we try to retain maximum functionality after close() we
> also allow errors to propagate as shown above.
>
> If anyone is curious the basic strategy we use in response to close
> functions (like close(), terminate(), and for UA-generated events like
> when the main worker object is GC'd) can be found in the following
> table:
>
>
> http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202
>
> -Ben
>
> On Tue, Mar 30, 2010 at 6:38 PM, Dmitry Titov wrote:
> >
> > On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson
> wrote:
> >>
> >> I'll note that the spec gives the UA an significant amount of latitude
> >> about its behavior after close() is called:
> >> User agents may invoke the "kill a worker" processing model on a worker
> at
> >> any time, e.g. in response to user requests, in response to CPU quota
> >> management, or when a worker stops being an active needed worker if the
> >> worker continues executing even after its closing flag was set to true.
> >> Essentially, UAs can kill a worker at any time, and since the "kill a
> >> worker" algorithm allows UAs to abort the script after a
> user-agent-defined
> >> amount of time (including zero), it seems like almost any behavior
> >> post-close is compliant. This seems like a guaranteed source of
> >> cross-browser incompatibilities.
> >
> > Yes, and this, after many hours of troubles, may eventually crystallize
> into
> > "don't have any code after close() in your worker code" rule-of-thumb for
> > web developers. Which is basically a bad thing...
> > This is why it could be better to specify explicitly that either
> execution
> > is immediately terminated or it runs until JS exits with full
> functionality
> > of the worker, not in a special almost-closed mode. Having a timeout
> >
> >>
> >> I've always operated under the impression that the intent of the spec is
> >> to allow pending worker operations to complete, but still give UAs the
> >> ability to abort scripts that don't exit in a timely manner (so close()
> >> should not immediately abort the script), but I don't see anything in
> the
> >> spec regarding this.
> >> For #2 below, I believe that exceptions in worker context should
> *always*
> >> be reported, regardless of closing state. Section 4.6 (Runtime script
> >> errors) makes no mention of tying this behavior to the closing flag.
> >
> > This applies as long as the browser still executes the code after
> close().
> > In WebKit V8 case, we terminate execution almost instantly, so we don't
> even
> > run the code that causes an error :-) If we are not to terminate
> execution
> > instantly, then it'd be nice to say the script runs until it ends (or
> parent
> > document closes, which actually terminates the script forcefully), and
> not
> > have a requirement to stop the queue or disconnect ports, as to not
> create a
> > whole new 'mode of worker execution' which needs to have a spec on its
> own
> > since all other features will need to be mentions (like sync APIs).
> > It's not clear why a fixed timeout would be useful. It would create some
> > randomness in what a worker can still do after calling close(). I think
> web
> > developers would then rather do those things before calling close(), to
> > avoid
Re: [whatwg] Web Workers feedback
On Wed, 31 Mar 2010, Anne van Kesteren wrote: > On Tue, 30 Mar 2010 15:09:49 -0700, Ian Hickson wrote: > > On Tue, 30 Mar 2010, Jonas Sicking wrote: > > > Personally my guess it's more likely that they really wanted to. > > > > I have no idea which is more likely. The only use case I'm aware of is > > passing an in, and for that there isn't really a fallback position, > > so it doesn't matter if we send null or throw an exception. > > Isn't the fallback there to draw the on a and then extract an > ImageData object and pass that through to the worker? For the use cases that were mentioned -- rotating or resizing an image -- it's actually slower to do it that way than just to do it on the main thread. (I expect for that use case we'll just add a dedicated API for async batch resizing and rotating of images.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers: What can be done in a worker after call to close()?
Hi,
When implementing the close() function for Firefox we chose to set the
closing flag and clear pending events only. As the worker script is
calling close() on itself we figured that the worker should retain
maximum functionality until it has finished execution (otherwise it
could just not call close() and rely on some kind of postMessage() and
terminate() combo). Therefore we do not enforce any timeout for the
currently executing script and we continue to allow postMessage()
calls and synchronous XHR to proceed. Since the closing flag is set in
response to close() the worker is guaranteed to finish as soon as the
currently running script finishes. We always enforce a timeout for any
code that runs in response to the close event that gets fired after
the current script finishes, though.
If the code that calls close() never returns (like the while(1) { }
example above) then the worker will never finish, as pointed out
above, but that's no different than having a worker script that
consists only of a while(1) { } loop and we don't think it's important
to prevent. If a worker script is written in this way then a
terminate() call is still a valid solution.
Also, since we try to retain maximum functionality after close() we
also allow errors to propagate as shown above.
If anyone is curious the basic strategy we use in response to close
functions (like close(), terminate(), and for UA-generated events like
when the main worker object is GC'd) can be found in the following
table:
http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202
-Ben
On Tue, Mar 30, 2010 at 6:38 PM, Dmitry Titov wrote:
>
> On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson wrote:
>>
>> I'll note that the spec gives the UA an significant amount of latitude
>> about its behavior after close() is called:
>> User agents may invoke the "kill a worker" processing model on a worker at
>> any time, e.g. in response to user requests, in response to CPU quota
>> management, or when a worker stops being an active needed worker if the
>> worker continues executing even after its closing flag was set to true.
>> Essentially, UAs can kill a worker at any time, and since the "kill a
>> worker" algorithm allows UAs to abort the script after a user-agent-defined
>> amount of time (including zero), it seems like almost any behavior
>> post-close is compliant. This seems like a guaranteed source of
>> cross-browser incompatibilities.
>
> Yes, and this, after many hours of troubles, may eventually crystallize into
> "don't have any code after close() in your worker code" rule-of-thumb for
> web developers. Which is basically a bad thing...
> This is why it could be better to specify explicitly that either execution
> is immediately terminated or it runs until JS exits with full functionality
> of the worker, not in a special almost-closed mode. Having a timeout
>
>>
>> I've always operated under the impression that the intent of the spec is
>> to allow pending worker operations to complete, but still give UAs the
>> ability to abort scripts that don't exit in a timely manner (so close()
>> should not immediately abort the script), but I don't see anything in the
>> spec regarding this.
>> For #2 below, I believe that exceptions in worker context should *always*
>> be reported, regardless of closing state. Section 4.6 (Runtime script
>> errors) makes no mention of tying this behavior to the closing flag.
>
> This applies as long as the browser still executes the code after close().
> In WebKit V8 case, we terminate execution almost instantly, so we don't even
> run the code that causes an error :-) If we are not to terminate execution
> instantly, then it'd be nice to say the script runs until it ends (or parent
> document closes, which actually terminates the script forcefully), and not
> have a requirement to stop the queue or disconnect ports, as to not create a
> whole new 'mode of worker execution' which needs to have a spec on its own
> since all other features will need to be mentions (like sync APIs).
> It's not clear why a fixed timeout would be useful. It would create some
> randomness in what a worker can still do after calling close(). I think web
> developers would then rather do those things before calling close(), to
> avoid random results.
> But if we say close() lets script run until completion (but prevents further
> messages/events from dispatching), then perhaps we don't need it at all -
> there is nothing then that script in the worker can not do to the same
> effect (unregister onmessage, clear timers etc).
> That means letting worker to call close() on itself only makes additional
> sense if it is specified as immediate termination. It could be useful and it
> can be specified in deterministic manner.
> On a separate note, I agree with giving workers some time before terminating
> them in case the parent page closes - but this is the case when forces
> outside and async to the worker need to close it. I think
Re: [whatwg] Web Workers feedback
On Tue, 30 Mar 2010 15:09:49 -0700, Ian Hickson wrote: On Tue, 30 Mar 2010, Jonas Sicking wrote: Personally my guess it's more likely that they really wanted to. I have no idea which is more likely. The only use case I'm aware of is passing an in, and for that there isn't really a fallback position, so it doesn't matter if we send null or throw an exception. Isn't the fallback there to draw the on a and then extract an ImageData object and pass that through to the worker? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Character encoding of document.open()ed documents
On Mar 31, 2010, at 16:24, Boris Zbarsky wrote: > On 3/31/10 7:12 AM, Henri Sivonen wrote: >> Currently, the spec says that document.open() sets the document's character >> encoding to UTF-16. This is what IE does except IE uses the label "unicode" >> instead of "UTF-16". >> Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/438 >> >> Gecko and WebKit set document's character encoding to UTF-8 even though the >> parser operates on UTF-16. >> Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/439 > > Is that what Gecko does? Or does it set the document's character encoding to > the character encoding of the page that called open()? I believe it's > actually the latter. > >> When loading external resources that don't have encoding labels, IE, Gecko >> and WebKit all use UTF-8 to decode the external resource. >> Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/437 > > Again, UTF-8 or the encoding of the page that called open()? Good point. Gecko sets the document's character encoding to UTF-8 and uses UTF-8 to decode the external resource. WebKit uses the encoding of the opener. IE8 (both with compat view button pressed and not pressed) sets the document's character encoding to "unicode" and uses UTF-8 to decode the external resource. Opera uses Windows-1252 to decode the external resource. http://hsivonen.iki.fi/test/moz/document-open-external-charset.htm >> None of IE, WebKit or Opera let the meta charset in a document.open()ed >> document have any effect > > As in, it doesn't affect how external resources with no encoding labels are > handled? Right. > Odd; I could have sworn it mattered in IE. I distinctly recall Gecko having > compat bugs of various sorts here for the external resource case at one point > (as in, people reporting intranet apps and the like that worked in IE but not > Gecko), and us trying pretty hard to fix them. It seems to me it doesn't matter even in IE6: http://hsivonen.iki.fi/test/moz/document-open-internal-charset.htm (WebKit seems to cache the charset of external resources, so it seems necessary to create a new incognito window in Chrome for each test run.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Character encoding of document.open()ed documents
On 3/31/10 7:12 AM, Henri Sivonen wrote: Currently, the spec says that document.open() sets the document's character encoding to UTF-16. This is what IE does except IE uses the label "unicode" instead of "UTF-16". Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/438 Gecko and WebKit set document's character encoding to UTF-8 even though the parser operates on UTF-16. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/439 Is that what Gecko does? Or does it set the document's character encoding to the character encoding of the page that called open()? I believe it's actually the latter. When loading external resources that don't have encoding labels, IE, Gecko and WebKit all use UTF-8 to decode the external resource. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/437 Again, UTF-8 or the encoding of the page that called open()? None of IE, WebKit or Opera let the meta charset in a document.open()ed document have any effect As in, it doesn't affect how external resources with no encoding labels are handled? Odd; I could have sworn it mattered in IE. I distinctly recall Gecko having compat bugs of various sorts here for the external resource case at one point (as in, people reporting intranet apps and the like that worked in IE but not Gecko), and us trying pretty hard to fix them. -Boris
[whatwg] Character encoding of document.open()ed documents
Currently, the spec says that document.open() sets the document's character encoding to UTF-16. This is what IE does except IE uses the label "unicode" instead of "UTF-16". Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/438 Gecko and WebKit set document's character encoding to UTF-8 even though the parser operates on UTF-16. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/439 When loading external resources that don't have encoding labels, IE, Gecko and WebKit all use UTF-8 to decode the external resource. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/437 Opera doesn't support document.charset or document.characterSet, but demo 37 and the demos discussed below show that Opera applies the default encoding (Windows-1252) to external resources referenced from document.open()ed documents. Spec change request: Please change the spec to say that document.open() sets the document's character encoding to UTF-8 even though the parser operates on UTF-16 DOMStrings. My real interest in this topic isn't so much about the initial character encoding value but about the effect of on document.open()ed documents. Consider this demo in Gecko with the old HTML parser: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/434 The demo alerts two times: first showing the REPLACEMENT CHARACTER and then showing LATIN SMALL LETTER R WITH ACUTE. First, Gecko parses the document with UTF-8 as the document's character encoding. During that parse, the value ISO-8859-2 from the meta is added to the cache entry for this stream (see my earlier email about reloading document.open()ed documents). Then the document is implicitly reloaded with ISO-8859-2 as the document's character encoding. This was implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=255820 back when Gecko used UTF-16 instead of UTF-8 as the document's character encoding for document.open()ed docs and using UTF-16 for external resources made the external resources fail to parse. Curiously, the implicit reloading behavior isn't particularly robust. In some situations the reload doesn't happen. I don't know what the logic is. Demo with the order of meta and script swapped: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/435 None of IE, WebKit or Opera let the meta charset in a document.open()ed document have any effect, which seems to suggests that Gecko might be trying unnecessarily hard in this scenario. Due to the test case for https://bugzilla.mozilla.org/show_bug.cgi?id=255820 I made the meta charset change the document's character encoding (but not reload) when the HTML5 parser is enabled in Gecko. See demos 435 and 434 with html5.enable=true. However, now it seems it might be better to revert that change to align with IE and WebKit--unless sites now depend on the Gecko behavior. Do other browser vendors have data showing sites depending on Gecko's behavior when loading external resources for document.open()ed docs? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Video Tag Proposal
> It's from speaking to people at companies who've been bitten by this. > (It works something like "you will be ineligible for this substantial > discount if you implement Vorbis.") No quotable citation, sorry. It's the loophole that makes RAND potentially meaningless. Everyone supposedly pays a 'non-discriminitory' base 'fair' price for licensing that is rather high, but just about everyone who 'plays nice' gets a substantial discount. Compete with a pool member and watch the 'discount' evaporate. Ironically, this practice also led directly to some of Vorbis's early funding, though it mostly cuts the other way. Monty
Re: [whatwg] Video Tag Proposal
On 29 March 2010 00:03, Silvia Pfeiffer wrote: > On Mon, Mar 29, 2010 at 7:14 AM, David Gerard wrote: >> The catch with Vorbis is that if you support it, whoever owns the MP3 >> patents charges you a lot more. >> (That's why I have an MP3 player that does Ogg Vorbis but does not >> mention the fact in the packaging, documentation or advertising in any >> manner whatsoever.) > That would be crazy, cause no MP3 patents apply to Vorbis. You are > able to use Vorbis without an MP3 license and the MPEG-LA should not > be able to charge you more just because your want to support both > codecs in your product. I believe that would not be legal. > Do you have a concrete example, like a quote or something, that confirms this? It's from speaking to people at companies who've been bitten by this. (It works something like "you will be ineligible for this substantial discount if you implement Vorbis.") No quotable citation, sorry. - d.
Re: [whatwg] Video Tag Proposal
My statement was completely wrong. Nokia isn't in the H.264 pool. Here's the full list (PDF linked from this page): http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx My sincere apologies to Nokia for this claim. - d. On 31 March 2010 08:48, Aaron Franco wrote: > David, > > Could you provide some links to substantiate that comment? I'd love to read > about it. >> Nokia neglected to mention, at the time of their strident objection to >> Theora, that they get money from the H.264 patent pool.
Re: [whatwg] Video Tag Proposal
On 31 March 2010 02:07, Richard Watts wrote: > Given what I've seen of the utter incomprehension the computing > strategy people in general have of video, I suspect the actual reason > for resistance is some form of pure political idiocy centering on the > mobile companies lobbying to restrict video to things they already > (think they have) silicon to accelerate. Nokia neglected to mention, at the time of their strident objection to Theora, that they get money from the H.264 patent pool. - d.
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Wed, 31 Mar 2010 09:38:21 +0300, Jonas Sicking wrote:
On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky wrote:
On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount> X) {
doStuff();
Can bufferedAmount not change due to data actually hitting the network
during the execution of this code? As in, will all the someString data
be
buffered immediately after that send() call?
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop.
I'm certainly no EcmaScript expert but now I'm confused. What event would
that be? There is no 'onsent' event. Would bufferedAmount not change until
there is an 'onerror' or 'onclosed' event?
BR,
/niklas
We generally try to avoid "racy" variables since people don't expect
them. Consider for example
if (ws.bufferedAmount > X) {
setUpSomeState();
}
try {
doOtherThings();
}
finally {
if (ws.bufferedAmount > X) {
cleanUpState();
}
}
I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.
--
Niklas Beischer
Software Developer
Opera Software
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking wrote:
On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote:
On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking
wrote:
On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote:
On Tue, 23 Mar 2010, Anne van Kesteren wrote:
We (Opera) would prefer this too. I.e. to not impose details of the
protocol on the API.
If we're exposing nothing from the protocol, does that mean we
shouldn't
be exposing that the string converts to UTF-8 either?
While exposing the fact that strings are sent as UTF-8 does say
something about the protocol, I think it's still much more protocol
independent than including the message headers. The string has to be
serialized in some way, and it seems unlikely that any newly developed
protocol in the foreseeable future would use anything other than UTF-8
as serialization.
True, but if bufferedAmount does not byte for byte (or character for
character) match what is fed to the API, what does a few bytes
representing the current overhead matter? IIRC EcmaScript uses UTF-16,
which means that serialization will in most cases make the number of
actually buffered bytes differ from the number of bytes in the original
message buffer.
EcmaScript doesn't do any serialization so I'm not sure what you mean
here?
I meant the serialization in the WebSocket. Unless the protocol
implementation keeps track of exactly how its serialized buffer differs
from the original buffer it will not be able to give a correct answer to
how much of the original buffer is left to transfer.
And just because we currently use UTF-8 for
serialization doesn't mean that will always be the case. Thus API users
cannot rely on performing their own conversion to UTF-8 just to find out
exactly how many characters in their message have been sent.
My point was that using anything but UTF-8 is unlikely. So the
opposite of what you're saying here.
So you're saying binary is out of the question?
The fact remains that, unless we want to force implementors of the
protocol to match each byte sent over the network with a specific
character in the original message handed to the API, bufferedAmount
cannot
represent something unaffected by the protocol. And if we allow
bufferedAmount to be affected by the protocol, why not let it be decided
by the implementation whether or not to include protocol overhead?
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount > X) {
doStuff();
}
};
If this is implementation dependent then the above could reliably call
doStuff in one implementation, but reliably not another.
No, not reliably. The value of bufferedAmount may also depend on the
system the implementation is running on as well as its current network
connection. One combination might yield completely different results from
another. If the developer is not aware of that his code may generate
website incompatibilities between the same implementation running in two
different environments. Or even in the same environment but at different
times due to different network connection. Yes, my suggestion will add
another variable to the equation. And yes, I admit, that is most of the
time a really bad idea. But I maintain that it should make little
difference in this case.
/niklas
--
Niklas Beischer
Software Developer
Opera Software
