Re: [whatwg] Workers
On Wed, Nov 12, 2008 at 3:35 PM, Ian Hickson [EMAIL PROTECTED] wrote: (cc'ed whatwg -- sorry if that wasn't what you intended) On Wed, 27 Aug 2008, Michael Nordman wrote: Is it possible for a worker (shared or dedicated) to reload itself? Not currently. For dedicated workers, this can effectively be accomplished already by one of the two means of close()ing a worker and then starting a new one and then handing out ports as needed. But for shared workers, this is a more interesting question. Provided clients of the shared worker (those that have a reference to it) can be relied on to restart it upon onclose(), reload() would effectively happen. Are there any windows of time where a shared worker executes w/o a client having a reference it? Yes. Any worker can survive, e.g. if it has timers running, until its parent window (or any window that it ever spoke to) closes the document it is associated with. I don't really see the use case for self-reloading. Do scripts self-reload in general? For people who want to update script in SharedWorker, could they do it by making the SharedWorker merely a shell? The SharedWorker would create a Worker to do everything. If a reload is needed, then the SharedWorker closes the Worker and starts it again (just like the dedicated worker method described above). Dave
Re: [whatwg] Workers
On Thu, 13 Nov 2008, David Levin wrote: I don't really see the use case for self-reloading. Do scripts self-reload in general? For people who want to update script in SharedWorker, could they do it by making the SharedWorker merely a shell? The SharedWorker would create a Worker to do everything. If a reload is needed, then the SharedWorker closes the Worker and starts it again (just like the dedicated worker method described above). Yes, that would work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Questions on Workers spec
It looks like all of this is there in a just published update of the spec. On Wed, Nov 12, 2008 at 11:33 AM, Dmitry Titov [EMAIL PROTECTED] wrote: Hi, I have couple of questions about Workers: 1. The sample code looks as if setTimeout/clearTimeout/setInterval/clearInterval should be available to Workers (as methods of WorkerUtils?) but they are not explicitly specified on any interface. Should they be there? 2. It seems workers should be able to create workers (including creating 'themselves' in case of SharedWorker). It is especially useful for a SharedWorker to create dedicated workers - since one of the popular scenarios for it is likely a state container that communicates with UI pages while using dedicated workers to do other operations. Will spec include this? Thanks Dmitry
Re: [whatwg] Issue when Video currentTime used for seeking.
On Wed, Nov 12, 2008 at 3:16 AM, Chris Double [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
video_element.src=http://www.double.co.nz/video_test/ascannerdarkly480.ogg;;
video_element.currentTime=10;
video_element.play();
You can use:
v.src = foo.ogg;
v.addEventListener(loadedmetadata, function() { v.currentTime=10;
v.play(); }, false);
Yes we can use JS to have a work around. But there will be other problems.
Example, the above code make all the subsequent assignment of url to
v.src make movie start from 10th second. So again we need to add code
to remove the event listener. That make things complicated for Web
Developers, (see, all Web developers I know are JSP/Java, ASP/.Net or
Graphics Designers they all only cut and paste JavaScript code).
Re: [whatwg] Issue when Video currentTime used for seeking.
On Wed, Nov 12, 2008 at 3:24 AM, Chris Double [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: toKeyFrame - optional, boolean, default false. if true indicates goto the nearest keyframe of the value provided in secondsToSeek. this is to improve performance while avoiding bug https://bugzilla.mozilla.org/show_bug.cgi?id=463358 Good question. Should seeks go to the previous keyframe to the requested time, the next keyframe after the time, the closest keyframe, or the exact frame requested? The idea for toKeyFrame argument came from some flash video controls ie, when we silde the duration slider, these flash controls flips through frames quickly. At that time it dont really matter exactly which frame, it can be before or after which ever is EASY to find. Regarding that bug, I think it should be going to the last keyframe then decoding up to the point of the requested frame so it can display non-garbage data. I agree... .seek() will return the time to which it is seek-ed to. What time is that exactly? Is that the time of the actual frame the There are 2 situations after execution of .seek() 1. the video not doing seeking or completed seeking eg:- a) .seek(0) (a seek with 0 time) when the video is not already seeking) b) .seek(+n) when video is already at end of file these two cases it will return value same as .currentTime 2. the video is still seeking or not completed seeking .seek(n) should return the cumulative time to which it is being seek-ed. one issue I see here is, if the video duration is only 10 seconds and seek was called for 100 seconds, what should seek() I feel for consistency we should return 100, ie with or with out metadata we will be able to provide same value.
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Alexey Proskuryakov wrote: Nov 6, 2008, в 2:18 AM, Jonas Sicking написал(а): Similarly, having separate interfaces for Worker and SharedWorker implies that there is some fundamental difference in their behavior - a difference that eludes me so far. A shared worker is shared between all scripts on a single site[*] that instantiates a worker with the same name. I.e. where the second argument to the constructor is the same. (Don't remember what happens if the second argument is the same as an existing worker, but the first is not, check with the spec). Sure, that part is clear - but it's only about the behavior of the object's constructor, not the object itself! It alone doesn't warrant having a separate interface. As an example from another area, see mmap(2) function - you can pass MAP_ANON or MAP_FILE via its flags to achieve similar results. Note also that it has a number of other options. If we create a separate interface for every Worker isolation level needed (both inside and outside), we'll soon end up with PrivateWorker, SharedDataWorker and who knows what else. So at this point the main problem with making any changes is that we are very close to shipping Firefox 3.1. I.e. it is extremely hard to make changes. It is very unfortunate that we have ended up in this situation again. We were in a very similar to the window.postMessage API where we had to scramble last minute to make changes, the result that time was that security issues in the API slipped by since those changes happened after we had done our security review of the spec. A few months ago representatives from google, apple, and mozilla met to try to agree to an API. We came up with a few guidelines, such as that it was ok to have a separate API for shared and dedicated workers as well as others that I don't specifically remember. At the end of the meeting we had a rough sketch of an API. A few days after that Hixie published a proposal. At mozilla we were largely fine with the proposal modulo some details that we commented on fairly quickly and then proceeded to implement. Now, months later, both google and apple is asking for some pretty significant changes, including reverting things like separate APIs for shared and dedicated workers. It is very close to release for us and we are already in a very frozen state, so making changes at this point is somewhere between risky and impossible. If we really want to make changes to the spec, we better make them really fast, ideally within a day or two. And depending on the complexity of the changes we might still be able to do them. The other alternative is of course removing workers from FF 3.1 and waiting until next release (judging by past releases, somewhere between a year or two from now). Finally, we can simply stick with the current API, none of the complains about the current syntax seems to have been very catastrophic, such as doesn't satisfy use cases, hard to understand, easy to have hard-to-discover bugs, etc. They mostly seem to be syntactic and the case of the matter is as always that there is no perfect syntax as the problem is over constrained. I see lots of ideas floating around but many of them are severly lacking in detail so it's hard to comment on. Things like 'rename startConversation to connect' is very ambiguous as has shown by recent discussions. So what follows is an effort to try to focus in on some discussed changes more concretely: The main two things that people seem to dislike in the current are 1. The many communication mechanisms. 2. Different APIs for shared and dedicated workers. I've said before that I don't really think 1 is true. There is currently one communication mechanism (postMessage/onmessage) and one connection mechanism (onconnect). There is also one convenience function on top of the communication mechanism (startConversaion), but is a stretch to call it a separate communication mechanism. The communication mechanism (postMessage/onmessage) does come in two flavors though as you for shared workers and dedicated workers call the functions on different objects. 2 I think is as much of a feature as a bug. Dedicated workers are by nature simpler since there is a one-to-one relationship between browsing context and worker rather than a many-to-one. So by having different APIs we can allow the dedicated worker API to be simpler. That said, I do agree that it is unfortunate that the mechanisms are different. So, here are some concrete proposals for a few changes we can make, and comments i've heard/made about them. The changes refer to the *current draft*, so please check the behavior defined there. * Remove startConversation Details: Simply remove the startConversaion function on all interfaces where it is defined. Since it doesn't define any new events no other changes are needed. Comments: There seemed to be opinions before on that it should definitely be removed, however it sounds like that is less the case now. I don't
Re: [whatwg] Scripted querying of video capabilities
did this thread go anywhere ?i'm concerned about the maybe case - looks way too much like: http://en.wikipedia.org/wiki/DShow#Codec_hell also - when you probe for mime type, do you mean the entire type parameter (including the codecs string) ? for example, there are too many cases where just passing video/mp4 would be insufficient. (fragmented index support ? base/main/high profile ? paff ? cabac ?) source src=video.mp4 type=video/mp4; codecs=quot;avc1.42E01E, mp4a.40.2quot; On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote: On Tue, 14 Oct 2008, Robert O'Callahan wrote: On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: While the underlying media frameworks can't necessarily answer, if I give you a file with this MIME type, can you play it?, they can at least give a yes/no/maybe answer, which can still be quite helpful, since the UA will know it does not need to check some media streams at all. I agree. If the API lets us answer maybe, there is not much need or temptation to lie, and we can still return information that could be useful to scripts. I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses. This API would be tempting to treat as a boolean but would of course do completely the wrong thing. I think it would be better to either ensure that the positive and neutral responses are both values that JS would treat as true (for instance make the values true, maybe and false), or else make all of the return values something self-descriptive and symbolic (for instance the strings yes, maybe and no). I think 1, 0, -1 are neither clear nor likely to be in any way beneficial for perforamnce. Regards, Maciej
Re: [whatwg] Scripted querying of video capabilities
On Nov 13, 2008, at 10:52 AM, Jeremy Doig wrote: did this thread go anywhere ? See http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-navigator-canplaytype . i'm concerned about the maybe case - looks way too much like: http://en.wikipedia.org/wiki/DShow#Codec_hell also - when you probe for mime type, do you mean the entire type parameter (including the codecs string) ? for example, there are too many cases where just passing video/mp4 would be insufficient. (fragmented index support ? base/main/high profile ? paff ? cabac ?) source src=video.mp4 type=video/mp4; codecs=quot;avc1.42E01E, mp4a.40.2quot; My interpretation is that it does, and the vagueness of many MIME types is the reason for the maybe case. eric On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote: On Tue, 14 Oct 2008, Robert O'Callahan wrote: On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: While the underlying media frameworks can't necessarily answer, if I give you a file with this MIME type, can you play it?, they can at least give a yes/no/maybe answer, which can still be quite helpful, since the UA will know it does not need to check some media streams at all. I agree. If the API lets us answer maybe, there is not much need or temptation to lie, and we can still return information that could be useful to scripts. I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses. This API would be tempting to treat as a boolean but would of course do completely the wrong thing. I think it would be better to either ensure that the positive and neutral responses are both values that JS would treat as true (for instance make the values true, maybe and false), or else make all of the return values something self- descriptive and symbolic (for instance the strings yes, maybe and no). I think 1, 0, -1 are neither clear nor likely to be in any way beneficial for perforamnce. Regards, Maciej
Re: [whatwg] Scripted querying of video capabilities
I'm also a bit concerned about how to interpret the yes, no and maybe return values. The truthful answer is going to be maybe for all but the obviously unsupport (application/x-ms-dos-executable) and the more trivial formats (audio/wav). When asking about application/ogg, this could mean 2 things: 1. can I demux Ogg 2. can I demux Ogg and decode an unknown codec If to answer yes the browser must be certain that it can play back all content which could have the requested mime type then the answer must always be maybe for container formats, e.g. video/avi, video/x-msvideo, application/ogg, video/mp4, video/mpeg and so on. Only if the codecs parameter is used is it ever possible to anwer yes It's hardly ever possible to answer no either, unless the underlying media framework explicitly doesn't support a When faced with something unrecognized the safest thing is to say maybe. To sum up, the answer is always maybe. This is nice for implementors who don't need to write a lot of code, but it's not useful. To fix this, I would suggest the following: If the mime type is just a container format then the browser may answer yes if it knows that it supports at least some content in that format (again, it's difficult without On Thu, 2008-11-13 at 10:52 -0800, Jeremy Doig wrote: did this thread go anywhere ? i'm concerned about the maybe case - looks way too much like: http://en.wikipedia.org/wiki/DShow#Codec_hell also - when you probe for mime type, do you mean the entire type parameter (including the codecs string) ? for example, there are too many cases where just passing video/mp4 would be insufficient. (fragmented index support ? base/main/high profile ? paff ? cabac ?) source src=video.mp4 type=video/mp4; codecs=quot;avc1.42E01E, mp4a.40.2quot; On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote: On Tue, 14 Oct 2008, Robert O'Callahan wrote: On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: While the underlying media frameworks can't necessarily answer, if I give you a file with this MIME type, can you play it?, they can at least give a yes/no/maybe answer, which can still be quite helpful, since the UA will know it does not need to check some media streams at all. I agree. If the API lets us answer maybe, there is not much need or temptation to lie, and we can still return information that could be useful to scripts. I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or -1 to represent positive, neutral, and negative responses. This API would be tempting to treat as a boolean but would of course do completely the wrong thing. I think it would be better to either ensure that the positive and neutral responses are both values that JS would treat as true (for instance make the values true, maybe and false), or else make all of the return values something self-descriptive and symbolic (for instance the strings yes, maybe and no). I think 1, 0, -1 are neither clear nor likely to be in any way beneficial for perforamnce. Regards, Maciej -- Philip Jägenstedt Opera Software
Re: [whatwg] Scripted querying of video capabilities
On Fri, Nov 14, 2008 at 8:19 AM, Eric Carlson [EMAIL PROTECTED]wrote: See http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-navigator-canplaytype . There was widespread dissatisfaction with the form of the API. I think it would be a lot better if there were two methods returning booleans, say, canPlayType and cannotPlayType. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
2008/11/13 Jonas Sicking [EMAIL PROTECTED]: So at this point the main problem with making any changes is that we are very close to shipping Firefox 3.1. I.e. it is extremely hard to make changes. It is very unfortunate that we have ended up in this situation again. We were in a very similar to the window.postMessage API where we had to scramble last minute to make changes, the result that time was that security issues in the API slipped by since those changes happened after we had done our security review of the spec. A few months ago representatives from google, apple, and mozilla met to try to agree to an API. We came up with a few guidelines, such as that it was ok to have a separate API for shared and dedicated workers as well as others that I don't specifically remember. At the end of the meeting we had a rough sketch of an API. A few days after that Hixie published a proposal. At mozilla we were largely fine with the proposal modulo some details that we commented on fairly quickly and then proceeded to implement. Now, months later, both google and apple is asking for some pretty significant changes, including reverting things like separate APIs for shared and dedicated workers. It is very close to release for us and we are already in a very frozen state, so making changes at this point is somewhere between risky and impossible. HIxie's draft after that meeting was August 20 (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015853.html), and my reply on this issue was Sep 12 (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html). Not stellar turnaround, but not months either. In any case, I can definitely appreciate the timing is poor for Mozilla and apologize for that. If we really want to make changes to the spec, we better make them really fast, ideally within a day or two. And depending on the complexity of the changes we might still be able to do them. The other alternative is of course removing workers from FF 3.1 and waiting until next release (judging by past releases, somewhere between a year or two from now). Finally, we can simply stick with the current API, none of the complains about the current syntax seems to have been very catastrophic, such as doesn't satisfy use cases, hard to understand, easy to have hard-to-discover bugs, etc. They mostly seem to be syntactic and the case of the matter is as always that there is no perfect syntax as the problem is over constrained. This is true, the worst I can think of happening as a result of the API Mozilla is planning no shipping would be frustrating for developers or frustrating for implementors as more feature are added that don't fit well. I see lots of ideas floating around but many of them are severly lacking in detail so it's hard to comment on. Things like 'rename startConversation to connect' is very ambiguous as has shown by recent discussions. So what follows is an effort to try to focus in on some discussed changes more concretely: Thanks for restating the various proposals so well... The main two things that people seem to dislike in the current are 1. The many communication mechanisms. 2. Different APIs for shared and dedicated workers. I've said before that I don't really think 1 is true. There is currently one communication mechanism (postMessage/onmessage) and one connection mechanism (onconnect). There is also one convenience function on top of the communication mechanism (startConversaion), but is a stretch to call it a separate communication mechanism. The communication mechanism (postMessage/onmessage) does come in two flavors though as you for shared workers and dedicated workers call the functions on different objects. Ok, maybe 'mechanism' was not the right word, but there are still three separate ways to use the external API to workers (not counting passing a port as an argument). I think this is undesirable. Here are my preference on changes, in descending order: * Add a connect() method to Worker and/or SharedWorker There has been lots of talk about this, but I'm still confused as to what the exact proposals are due to lack of details. But here is my interpretation Details: - Make instantiating a SharedWorker *not* fire a 'connect' event automatically. - Remove the .port property from SharedWorker - Remove the postMessage/onmessage functions from Worker and DedicatedWorkerGlobalScope - Add a onconnect property on WorkerGlobalScope - Add a connect() method on AbstractWorker. The function fires a 'connect' even on the WorkerGlobalScope, the event has a .port property which is a MessagePort. This MessagePort is entangled with another MessagePort which is the value from the connect() function. Comments: Compared to just doing the other above proposals I think this adds needless complexion for value that I don't quite see. If you want to have several 'conversations', I.e. several separate
Re: [whatwg] Scripted querying of video capabilities
On Fri, Nov 14, 2008 at 8:38 AM, Philip Jägenstedt [EMAIL PROTECTED]wrote: I'm also a bit concerned about how to interpret the yes, no and maybe return values. The truthful answer is going to be maybe for all but the obviously unsupporter (application/x-ms-dos-executable) and the more trivial formats (audio/wav). Even WAV is extensible. When asking about application/ogg, this could mean 2 things: 1. can I demux Ogg streams? 2. can I demux Ogg streams and decode unknown codecs? It means can I play this stream, given that the only thing I know about it is that it's an Ogg stream? Which I guess is what you meant by option 2. The browser can only answer no or maybe in this case. That seems fine to me. It lets the author know whether the browser can demux Ogg streams, while staying consistent with the behaviour when codec information is given in the MIME type. Unless the codecs parameter is to be made mandatory I think that spec should explicitly make it such that the question asked is 1. In either case we will end up there because 2 is not a meaningful question and user agents will make untruthful answers in attempts to stay compatible with unknown and future content (which might be supported by installing new codecs in the media framework without upgrading the browser). I don't understand what the incentives are for browsers to lie. If we start off telling the truth, then authors will have to write scripts that either accept maybe or, better still, provide the codec information, or their scripts won't work. I don't see how that would change over time. Now, if the codec parameter is used then the user agent may answer yes and no in a way that actually makes some sense. Yes. Authors should be strongly encouraged to give the codec parameters. I also think that this should be explicitly related to the type attribute of the source element. One should be able to use canPlayType to predict with 100% accuracy which source the user agent will use when it encounters. video source type=application/ogg/ source type=application/ogg codecs=dirac,flac/ /video If this isn't specified then one can expect lots of web app authors being forced to write scripts to work around the different behaviour of canPlayType and the pick a source algorithm in different browsers. I agree. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Scripted querying of video capabilities
On Fri, Nov 14, 2008 at 6:38 AM, Philip Jägenstedt [EMAIL PROTECTED] wrote: Now, if the codec parameter is used then the user agent may answer yes and no in a way that actually makes some sense. I also think that this should be explicitly related to the type attribute of the source element. One should be able to use canPlayType to predict with 100% accuracy which source the user agent will use when it encounters. video source type=application/ogg/ source type=application/ogg codecs=dirac,flac/ /video On a little bit of a side not, may I point out that there is an updated RFC for Ogg media types at http://www.ietf.org/rfc/rfc5334.txt and it explicitly includes the codecs parameter with standard values for the current ones supported by Ogg. It also recommends using video/ogg for video files, so that would change your example to: video source type=video/ogg/ source type=video/ogg; codecs=dirac,flac/ /video I know it's a minor issue, but I'd like us at HTML5 to get it right and to recommend the correct mime types to web developers. Cheers, Silvia.
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Here are my preference on changes, in descending order: * Add a connect() method to Worker and/or SharedWorker There has been lots of talk about this, but I'm still confused as to what the exact proposals are due to lack of details. But here is my interpretation Details: - Make instantiating a SharedWorker *not* fire a 'connect' event automatically. - Remove the .port property from SharedWorker - Remove the postMessage/onmessage functions from Worker and DedicatedWorkerGlobalScope - Add a onconnect property on WorkerGlobalScope - Add a connect() method on AbstractWorker. The function fires a 'connect' even on the WorkerGlobalScope, the event has a .port property which is a MessagePort. This MessagePort is entangled with another MessagePort which is the value from the connect() function. Comments: Compared to just doing the other above proposals I think this adds needless complexion for value that I don't quite see. If you want to have several 'conversations', I.e. several separate MessagePorts, with a dedicated worker you can use postMessage and |new MessageChannel| (or the startConversation shorthand) to accomplish that. If you want several conversations with a dedicated worker you can do the same thing, or even call |new SharedWorker| multiple times. I think this is the best API because it offers the most functionality with the smallest area. I also like that the API for dedicated and shared workers is identical because it means that one you learn to use dedicated workers, you already know how to use shared workers. Comparing to doing the other set of changes the differences in API are as follows: - Add a 'connect()' method on AbstractWorker which must be called every time after instantiating a worker. - The postMessage/onmessage functions are moved from the worker object to the port object. To me this seems like strictly a bigger API. As far as functionality goes the differences are as follows: - You have to deal with two separate objects, the port and the worker. - You can create multiple communication channels with a worker by calling connect() multiple times. Only the second thing here seems like a win. And only for dedicated workers since for shared workers you can simply call |new SharedWorker| multiple times if you want multiple communication channels. So it seems to me like the pros and cons fall out as: Pros: - Easier to create multiple connection channels to dedicated workers Cons: - Bigger API (an extra connect() function) - More code required (an extra call to connect() required) - More objects (port and worker) To me the cons outweigh the pros here. Is there a goal with connect() that I'm missing? * Remove startConversation Details: Simply remove the startConversaion function on all interfaces where it is defined. Since it doesn't define any new events no other changes are needed. Comments: There seemed to be opinions before on that it should definitely be removed, however it sounds like that is less the case now. I don't really care about this one. startConversation is just a convenience function on top of postMessage anyway. If there still is any disagreement about its neccessity or the fact that it adds to that we have too many communication mechanisms i'd prefer we remove it for now and then discuss it once we've agreed on the rest of the API, or we can let it be for this version of the spec. Others have commented that startConversation is a red herring in these discussions, I agree. (This would be no problem for us since we don't implement startConversation yet). If we don't make the above change, I think that we should remove startConversation(). It doesn't offer enough different functionality over passing a |new MessageChannel().port2| to be worth the extra API IMO. No, this is *exactly* the same functionality as passing |new MessageChannel().port2| through postMessage. Why does *not* making the above change (I assume adding connect()?) mean that we should remove startConversaion? I would have thought that the opposite would be true. Keeping startConversation makes much sense if we don't have connect() as both functions set up a 'conversation'. * Make the external API for shared workers that of the current dedicated worker ... I don't have a strong opinion on this. * Make dedicated workers receive a 'connect' event when they are created ... I don't have a strong opinion on this. Hmm.. I thought that the reason we are having this whole discussion was because there was dislike around the fact that dedicated and shared workers have different APIs. This also resulted in more communication APIs as the communication APIs were different. The above two changes fixes exactly that so I'm surprised you have no strong opinion on it. At this point I have to ask what the problem you are trying to solve is? What is wrong with the current spec as is? I.e. rather than talking about various proposals, maybe we
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Nov 14, 2008, в 1:20 AM, Jonas Sicking написал(а): If we don't make the above change, I think that we should remove startConversation(). It doesn't offer enough different functionality over passing a |new MessageChannel().port2| to be worth the extra API IMO. No, this is *exactly* the same functionality as passing |new MessageChannel().port2| through postMessage. For the sake of completeness, a connect/startConversation method on a worker really should automatically open the receiving port - this is what examples posted so far implied, and it would cause a lot of aggravation if it didn't. I know I'm often forgetting to open the port when writing my tests, and it's not a very easy mistake to spot. So, even though the current spec doesn't say this, there should be some difference in behavior. At this point I have to ask what the problem you are trying to solve is? What is wrong with the current spec as is? Not speaking for Aaron, of course, but... Besides API usability that we've already discussed back and forth without reaching an agreement, I'm very much concerned about the current spec being implementable in its current form. It has a lot of notions and algorithms that are not correctly defined. For a randomly picked example: - Each WorkerGlobalScope worker global scope has a list of the worker's ports, which consists of all the MessagePort objects that are entangled with another port and that have one (but only one) port owned by worker global scope. This list includes all the MessagePort objects that are in events pending in the queue of events, as well as the implicit MessagePort in the case of dedicated workers. - In an async processing model, there is simply no way for the receiver to have a list of all objects that were posted to it - it's exactly the reason for the existence of the queue that events are delivered asynchronously and cannot be peeked before being delivered. For example, in a multi-process implementation, these events may still be across process boundary. Also (from HTML5): - Each MessagePort object can be entangled with another (a symmetric relationship). - It is not possible to have a symmetric relationship in an asynchronous messaging model - we need a multi-step entagling/unentangling protocol, so the relationship is necessarily asymmetric. One can't freeze another process (or really, even another thread) to change something in it synchronously. Some instances of implied synchronous thinking can be corrected rather easily, but not all of them. So, I do not really see how anyone can claim implementing the spec, or even a subset of it at this point. - WBR, Alexey Proskuryakov
[whatwg] Workers feedback
I haven't written a summary of changes because this is a rather involved issue and I'd like everyone who has an opinion to actually read this. I missed a few e-mails sent in the last few hours in this reply, as I started this yesterday. I'll read and respond to those in a bit. On Thu, 28 Aug 2008, Jonas Sicking wrote: The spec currently says: Once the WorkerGlobalScope's closing flag is set to true, the queue must discard anything else that would be added to it. Effectively, once the closing flag is true, timers stop firing, notifications for all pending asynchronous operations are dropped, etc. Does this mean that anything already on the queue will remain there? Or will it be dropped? It sounds like it will remain, but it's somewhat unclear. I've added a parenthetical clarifying this. In general I think the three shutdown mechanisms that exist are somewhat messy: * Kill a worker * Terminate a worker * WorkerGlobalScope.close() It seems excessive with 3 possible shutdown sequences, but more importantly the differences between them seems unnecessarily big. Mostly for users, but to a small extent also for implementors. Currently the situation is as follows: | Abort | Processes | Fires| Fires | current | more | close on | close on | script | events| scope| tangled | | | | ports - WorkerGlobalScope.close() | No | Maybe[2] | Yes | Yes Kill a worker | Maybe[1]| Maybe[1] | Maybe[1] | No Terminate a worker| Yes | No| Yes | No - [1] Implementation dependent. Presumably depends on how much patience that the implementation thinks its users has. [2] Depends on if the event has been placed in the queue yet or not, somewhat racy. There are other ways to kill the worker: The worker is orphaned| Maybe[1]| Yes | Yes | No The browser dies | Yes | No| No | No Also, your No in the top-left cell is really a Maybe[1], since if the script doesn't stop then it'll trigger the Kill algorithm. This seems excessively messy. The number of differences in the columns and the number of maybes seems bad. I propose the following: * Remove the Kill a worker algorithm and use Terminate a worker everywhere it is used. I strongly disagree with that. The whole point of having a distinction is that we don't want scripts just being killed willy-nilly when the user navigates away from the page. Scripts in the page itself aren't terminated, why would we want such drastic behaviour in the threads? * Make WorkerGlobalScope.close() not process any more events. I.e. make setting the 'closing flag' to true always clear out all events except a single close event. Again, this seems bad as it would mean that if you navigated away from a page that happened to use a worker, you could get data loss. * Always fire close on tangled ports. In many cases this will be a no-op since we're doing it in workers that are being closed. However if the port is in another window or a shared worker this might not be the case. I thought we weren't doing this because it exposed the details of garbage collection? On Fri, 12 Sep 2008, Aaron Boodman wrote: * We have discussed having onerror expose runtime script errors that happened inside the worker. I don't think this makes sense for shared workers, so I propose that it be spec'd to only expose load errors. Script errors can still be exposed via a global onerror property inside the worker, and they can still be reported to the error console. I don't think having script errors that happened inside a worker be exposed outside it is that useful (load errors are useful, though). Right now only load errors are reported. I'll wait til the API is more stable before exposing script errors and the like at all (whether on a global onerror or whatever). It is noted as an XXX issues in the spec source. On Thu, 28 Aug 2008, Jonas Sicking wrote: Why is importScripts imposing a same origin restriction? This won't increase security in any way since cross-origin scripts can always be loaded from the main thread. I think cross-site loading is fairly common exactly for the case that importScripts, which is loading libraries. I don't recall the precise reason, but I seem to recall concern over specific attack vectors are what caused us to restrict this. Also, the spec doesn't seem clear on what to do if compiling a script fails. I think some sort of exception should be thrown, probably the same one that is thrown if eval() is given a non-compiling script. Done. On Tue, 30 Sep 2008, Alexey Proskuryakov wrote: I've been trying to
Re: [whatwg] Scripted querying of video capabilities
Pitching in here, I think it's OK if we want to go to a two-state answer -- but those answers are No and Maybe, not No and Yes. There are, after all, vanishingly small numbers of mime types where I can be 'completely' (within reason) confident of a 'yes' answer. On the other hand, given a mime type I simply don't recognize, or a codec I know I don't have, I can be confident of a No. Documenting it as providing a No/Maybe indication, and that how positive the 'Maybe' is depends to a large extent on how precise the supplied mime type is, would be fine by me, I think. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
On Thu, 13 Nov 2008, Alexey Proskuryakov wrote: I like that it doesn't tie Worker and MessagePort lifetimes too closely, which means that it has a higher chance of being paradox-free. Could you elaborate on this? I'm not sure I understand. What paradoxes might exist? On Thu, 13 Nov 2008, Jonas Sicking wrote: The main two things that people seem to dislike in the current are 1. The many communication mechanisms. 2. Different APIs for shared and dedicated workers. I've said before that I don't really think 1 is true. There is currently one communication mechanism (postMessage/onmessage) and one connection mechanism (onconnect). The communication mechanism (postMessage/ onmessage) does come in two flavors though as you for shared workers and dedicated workers call the functions on different objects. I agree that there is only one real communication mechanism, and I don't understand the problem with that. The onconnect mechanism is unfortunate, but I don't see any other good way to get the ports into the shared worker case. Certainly we don't want to force the dedicated worker users to have to use it, IMHO. 2 I think is as much of a feature as a bug. Dedicated workers are by nature simpler since there is a one-to-one relationship between browsing context and worker rather than a many-to-one. So by having different APIs we can allow the dedicated worker API to be simpler. That said, I do agree that it is unfortunate that the mechanisms are different. Agreed, somewhat. So, here are some concrete proposals for a few changes we can make, and comments i've heard/made about them. The changes refer to the *current draft*, so please check the behavior defined there. * Remove startConversation Details: Simply remove the startConversaion function on all interfaces where it is defined. Since it doesn't define any new events no other changes are needed. Done, for now. We might bring it back later, but it seemed simpler to remove it since it was causing confusion. * Make the external API for shared workers that of the current dedicated worker Details: Move the postMessage/onmessage functions from the SharedWorker.port object to the SharedWorker object. The SharedWorker would act as a MessagePort that is entangled with the port that is provided to the SharedWorkerGlobalScope through already specified 'connect' event that is fired when a SharedWorker is created. Comments: The result of this would be that on the outside shared workers and dedicated workers have exactly the same API to the outside world, except that dedicated workers have a terminate() function (formerly known as close(), changed in the latest version of the spec). Right. [...] Hixie expressed some dislike about the fact that we'd end up with MessagePort entangled with something that isn't a MessagePort. This can result in uglyness if the MessagePort is passed out outside the SharedWorker, and then passed on anywhere. A page could create a setup where calling postMessage on a SharedWorker object actually resulted in onmessage being called inside another window rather than inside a worker global scope. Right. There's also the problem with whether to expose .close(), start(), etc, on the SharedWorker object -- i.e. whether to flatten the whole MessagePort API in, or whether to only expose some parts -- in the latter case, we'd have a weird asymetry where e.g. the worker could call .close(), but the SharedWorker wouldn't get the close event, etc. I really don't like this. I don't really think this is a big deal though, you have a very similar situation today where calling postMessage on a SharedWorker.port object can do exactly the same thing. We could change .port to .getPort(), or .connect(), and have it return a new port. That would remove the artificial link between the SharedWorker object and the MessagePort. Would that work for people? * Make dedicated workers receive a 'connect' event when they are created Details: Make the internal communication API for a dedicated worker exactly that of what a shared worker is currently specced as. This means - Once a dedicated worker is instantiated automatically fire a 'connect' event which contains a MessagePort object (accessible through event.port). - Make the Worker object entangled with this MessagePort. - Remove the postMessage/onmessage functions from DedicatedWorkerGlobalScope Comments: I don't feel super strongly about this. From a purely dedicated worker perspective this doesn't really add any value but rather just complexity. Everyone using dedicated workers will have to set up a dummy function that just listens for a 'connect' event and sets a global port variable. The upside is that combined with the above change it makes the API for dedicated and shared workers exactly the same. This is what we used to have. People didn't like it, so much so that we ended up
Re: [whatwg] Workers feedback
I don't see any value in the user-agent specified amount of time delay in stopping scripts. How can you write cleanup code when you have no consistency in how long it gets to run (or if it runs at all)? If you can't rely on a cleanup then it becomes necessary to have some kind of repair/validation sequence run on the data next time it is accessed to check if it's valid. If you can do that then you didn't really need a cleanup anyway. As far as I can tell the user-agent specified amount of time is going to be a major source of hard-to-spot, hard-to-test bugs (since full testing probably involves closing and killing browsing contexts in different ways followed by a login sequence and several page navigations to get back to the page). I can see authors maybe performing these tests in IE but not across a range of browsers and computer specifications. The spec really needs to make a decision here. Either consistently provide no cleanup window or make it a requirement to provide a fixed number of seconds, which is still unreliable but at least within a smaller margin. Failure to do so will impact heavily on users of less popular browsers. The specification for message ports is still limited to strings. If no effort is going to be made to allow numbers, arrays, structs and binary data then I'd suggest Workers be given functions to serialise/deserialise these objects. Since the whole point of workers is presumably the processing of large datasets then a reliable and low-overhead means of passing these sets between workers and main threads (without resorting to SQL, XMLHttpRequest or other indirection) is an essential function. WorkerUtils does not implement document.cookie. I imagine this would be very useful in conjunction with cleanup code to flag if a cleanup operation failed to complete. Storage and Database interfaces are too heavy for the purpose of simple data like this. Shannon
Re: [whatwg] Workers feedback
On Fri, 14 Nov 2008, Shannon wrote: I don't see any value in the user-agent specified amount of time delay in stopping scripts. How can you write cleanup code when you have no consistency in how long it gets to run (or if it runs at all)? The user-agent specified amount of time delay is implemented by every major browser for every script they run today. How can people write clean code when they have no consistency in how long their scripts will run (or if they will run at all)? Why is this any different? If you can't rely on a cleanup then it becomes necessary to have some kind of repair/validation sequence run on the data next time it is accessed to check if it's valid. You need to do that anyway to handle powerouts and crashes. The spec really needs to make a decision here. Either consistently provide no cleanup window or make it a requirement to provide a fixed number of seconds, which is still unreliable but at least within a smaller margin. Failure to do so will impact heavily on users of less popular browsers. I don't see how this is any different than the current script abort timeout feature in browsers. The specification for message ports is still limited to strings. If no effort is going to be made to allow numbers, arrays, structs and binary data then I'd suggest Workers be given functions to serialise/deserialise these objects. We're going to add JSON-serialisable data support in due course. I'd rather get the rest of the API nailed down first though. WorkerUtils does not implement document.cookie. I imagine this would be very useful in conjunction with cleanup code to flag if a cleanup operation failed to complete. Storage and Database interfaces are too heavy for the purpose of simple data like this. It's not clear which document the cookie would be for. localStorage is as light-weight than cookies (lighter-weight, arguably), though, so that should be enough, no? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issue when Video currentTime used for seeking.
On Thu, Nov 13, 2008 at 10:48 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
On Wed, Nov 12, 2008 at 3:16 AM, Chris Double [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
video_element.src=http://www.double.co.nz/video_test/ascannerdarkly480.ogg;;
video_element.currentTime=10;
video_element.play();
You can use:
v.src = foo.ogg;
v.addEventListener(loadedmetadata, function() { v.currentTime=10;
v.play(); }, false);
Yes we can use JS to have a work around. But there will be other problems.
Example, the above code make all the subsequent assignment of url to
v.src make movie start from 10th second. So again we need to add code
to remove the event listener. That make things complicated for Web
Developers, (see, all Web developers I know are JSP/Java, ASP/.Net or
Graphics Designers they all only cut and paste JavaScript code).
I still feel rather dubious about the currentTime attribute of the
video element.
When it is used to tell a server about starting at an offset rather
than a the beginning, I'd prefer we rather use media fragment URIs
(once they are standardised by the W3C media fragment working group).
It will then be obvious that the user is actually asking for a subpart
of the resource to be displayed only. This is controlled by the author
of the Web page.
When it is used to change the current play pointer during watching of
a video, i.e. is controlled by the user of the Web page, it should
really be done through an event and javascript. Maybe the onclick
event can be defined for the video element here and it could call a
seek javascript function?
I feel very dubious about mixing these two use cases into the same attribute.
Best Regards,
Silvia.
Re: [whatwg] video tag : loop for ever
There were 81 e-mails on the topic of looping audio and video. I haven't included them here because they were mostly redundant. However, I read them all, and it seems that the use cases and feedback boiled down to these points: 1. Feedback: Simplify the API where possible; in particular start/end/ loopStart/loopEnd and so on. 2. Use case: looping complete tracks of background audio or video without glitches. 3. Use case: playing a track starting at a particular location without using script that waits for the media to load. 4. Use case: playing different media segments with only one HTTP request. To address point 1 I've removed all those attributes and related APIs. To address point 2 I've added a single attribute loop, which, when set, causes the UA to loop back to time=0 when the clip ends. To address point 3 I would like us to consider using recently begun work relating to fragment identifiers for media content. I have edited the spec so that it defers to the fragment identifier or any metadata in the resource, but I expect we will have to further tweak this. To address point 4 I would like to rely on a more generic solution that also addresses this for CSS, images, etc. This could be jar:, or it could me a MIME multipart solution, or offline caching, or data: URLs, or something else. However, I think this transcends the media API and therefore I haven't added anything specifically in this API to deal with it. If I have missed a key point, please do let me know. It's quite possible that I missed something when reading this thread as it was quite long and had a lot of repetition. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video : Slow motion, fast forward effects
On Wed, 15 Oct 2008, Charles Iliya Krempeaux wrote: On Wed, Oct 15, 2008 at 2:08 AM, Ian Hickson [EMAIL PROTECTED] wrote: Regarding whether to play audio while rewinding: Leaving this be something that is optional doesn't make sense to me. If we want interoperability, we need to either have all the browsers play sound while moving backwards through a sound or video file, or not play sound. Leaving things optional means that one author will test with one browser and expect one behavior, and then when the user uses that page on another browser, he will get unexpected behavior. For example, if Alice uses Browser A, and finds that when rewinding the sound isn't played, and thus does a hack that fakes the sound playback by having a separate hidden video element while rewinding, in which she seeks, plays forward for a bit, seeks, plays, etc, then when Bob loads that page in Browser B, which does play audio when rewinding, he'll get a horrible double audio effect. Or similarly, if Alice, in an attempt to get a cool effect, plays a bunch of videos backwards, and when the user selects one, plays it forward, then Bob will find that all the audio from all the videos plays simultaneously instead of all being muted except the video that Alice is expecting to play. So. We have to either require that backwards-playing audio be muted, or require that it play. I don't mind which. I've required that it be muted because implementors said playing would be hard. Could we make it configurable though?... So... the web developer could check if playing sound for this is available. And if it is available, they can turn it on (if they wanted to). And if it is not available, they can handle it in some way. We could, but this is something I'd leave for a future version, since browser vendors have already said that they don't want to support it today. On Wed, 15 Oct 2008, Peter Kasting wrote: * These use cases are really a stretch, compared to the much more plausible use case of simply allowing a user to scrub a video forwards or backwards. These aren't use cases, they're just examples of why we have to define this one way or the other. * All this still seems well-enough-solved if audio can be programmatically muted. The worst possible case is that the author, as you say, does not test in one browser, and causes another browser to have overlapped audio. Then users complain and the author is responsible and fixes their JS to mute the audio (hopefully simple), or they are lazy and don't. Neither one seems like catastrophe. As you say in your mail, authors act irrationally, and not all will fix their pages. But so what? If we don't define it, and some browsers do it and some don't, then eventually all browsers will be forced to do the same thing (probably mute when rewinding). Not defining things is an unstable equilibrium. In the meantime, we'll have wasted a bunch of engineering resources. By comparison, mandating that browsers play audio puts a great burden on browsers and codec authors (since the feasibility of reversed audio depends on the format, the OS, etc.), and mandating that they don't completely rules out whole classes of use cases. This cure is much worse than the disease. We can always add a new feature later that enables scrubbing audio when rewinding. If we don't define it, we're forcing it just as much, it's just that the forcing will happen mostly out of our control, and might end up being much more of a mess than if we pick one first. That's how a lot of HTML's most crazy quirks came about. We can get this by requiring that the user agent play _some_ audio, even if severely degraded, at all speeds including negative speeds. I'm happy to require that if people are ok with it. I don't see how this is any better than the no spec case you wanted to avoid. Use your previous argument again: an author tests in one browser, which plays reversed audio in a fashion he deems acceptable. The released app, played in another browser, sounds hideous. Users complain. But here, it's the less good browser that gets the bad effect, so the browser vendors end up forced towards the better behavior, not the worse behavior, as would happen otherwise. I don't see how an explicit attribute buys you anything more or less than explicit muting until the day when every browser respects that attribute in all cases -- and if our reason for not mandating reversed playback is that it's technically infeasible in some circumstances (which I think has merit), that's unlikely to ever happen. We can design the feature to indicate whether or not rewinding is going to give audio or not. On Wed, 15 Oct 2008, Kristof Zelechovski wrote: Requiring some audio to play is a good idea but it should be more precise. If the implementors are required to play some audio, they can do
Re: [whatwg] video tag: pixel aspect ratio
On Wed, 15 Oct 2008, Sander van Zoest wrote: source pixelratio=10:11 !-- 525 composite NTSC -- source pixelratio=59:54 !-- 625 composite PAL -- source pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- Currently pixelratio is a floating point number, as in: source pixelratio=0.909090909 !-- 525 composite NTSC -- source pixelratio=1.09259259 !-- 625 composite PAL -- source pixelratio=0.958568738 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- Is that not enough? I hate to say it, but if it was enough, I wouldn't be commenting here. It simply isn't accurate enough to store it as a float. Every respected container stores the ratio as X x Y. See the PASP atom for example. On Wed, 15 Oct 2008, Anne van Kesteren wrote: How is not accurate? In terms of precision it shouldn't really matter... I agree with Anne here. I've left the spec as is. Note that the whole point here is to discourage people from using the attribute. Also, it is intended only for use by people who are trying to fix a broken video; they might not know the right value, so it doesn't really matter so much whether the value that is used is precise or not, just so long as it improves the video relative to what it would be if the value in the video data file itself was assumed. On Wed, 15 Oct 2008, Sander van Zoest wrote: We are talking video here. Precision is at its core. If you consider the majority of the broken video out on the net today a good example of what you want more of then, I see no reason to accurately define PAR. [...] you can not accurately convert video on the fly if you do not have the exact ratio. All this stems from the conversion from analog to digital and in the analog world we did a lot of funky tricks to make things work better on hardware of those days, but as our computers and electronics in general get faster and faster, putting in inaccuracies can cause for some seriously ill side effects, now and especially in the future. The whole point here is that the video is wrong, and the author is trying to apply a last-minute hack to improve it a bit. If performance is an issue, then encode the video correctly and don't use the attribute at all. On Wed, 15 Oct 2008, Jonas Sicking wrote: I think if we make the syntax really simple like: 1. Find the first ':' 2. Parse the value before as an integer 3. Parse the value after as an integer then adding a new syntax is pretty cheap. Of course having separate attributes is even cheaper. But if the 10:11 syntax is really common then I think it might help authoring to use it. The whole point is to discourage authors from using it, so actually we sort of _want_ it to not help authoring. :-) On Wed, 15 Oct 2008, Eduard Pascual wrote: The issue is that, for most (probably all cases), the limitations of representation of floating numbers are a guarantee that the value will be wrong. It is not the same 0.909090909 that 0.909090909090909090... and that wouldn't still be the same that 10:11. Assume that we have a video that is 1 video pixels square. That's a 100 megapixel video. If we pretend that aspect ratio of the pixels is 11:11, then the video will, at 1:1 zoom, take 1 horizontal pixels (and 1 vertical pixels). If we assume that the pixel ratio is 10:11 = 0.9090909090909090909090909, and we keep the vertical number of pixels at 1, then it will be (rounding to 0dp) 9091 pixels wide. If we assume that the pixel ratio is just 10:11 = 0.90909 then it will STILL be (rounding to 0dp) 9091 pixels wide. In practice, videos are much smaller and displayed on much smaller displays. So, with all due respect, why is it not enough? Although the difference may seem negligible, simple image scaling algorythms tend to yield horribel results for slight scaling (you can try to render a PDF document at 101% zoom to see what I'm speaking about; especially one with images). The alternative, bilinear or trilinear scaling, could be too much of a strain for video: there is a higly noticeable difference between running such algorythm once and running it 25 or 30 times each second. If we add to the mix that pages might be including several videos; that most probably there is also audio playing along with the video, the computation cost of decoding, and the fact that not every user on the web (probably, not even the majority of them) uses a high end computer; then scaling needs to be quick and simple enough to achieve decent rendering without mass-frying CPUs. Scaling a video to 9090 pixels wide or 9091 pixels wide isn't going to show the artifacts you are talking about. I still don't understand why the spec has to define each and every parser algorythm (IMO, it should only define the syntax, and then the implementation should define its own algorythm that parses that syntax as defined) We have to define the parsers because the syntax alone
Re: [whatwg] Workers feedback
Ian Hickson wrote: On Fri, 14 Nov 2008, Shannon wrote: I don't see any value in the user-agent specified amount of time delay in stopping scripts. How can you write cleanup code when you have no consistency in how long it gets to run (or if it runs at all)? The user-agent specified amount of time delay is implemented by every major browser for every script they run today. How can people write clean code when they have no consistency in how long their scripts will run (or if they will run at all)? Why is this any different? For what it's worth we set all user-agent specified amount of time times as close to 0 as we can in our implementation. There's always a tiny amount of delay in cross-thread communication, in the order of fractions of a second. The specification for message ports is still limited to strings. If no effort is going to be made to allow numbers, arrays, structs and binary data then I'd suggest Workers be given functions to serialise/deserialise these objects. We're going to add JSON-serialisable data support in due course. I'd rather get the rest of the API nailed down first though. For what it's worth we support the ECMAScript JSON object inside the worker (along with things like Math and Date) which means that you can manually JSON-ify you objects when communicating. WorkerUtils does not implement document.cookie. I imagine this would be very useful in conjunction with cleanup code to flag if a cleanup operation failed to complete. Storage and Database interfaces are too heavy for the purpose of simple data like this. It's not clear which document the cookie would be for. localStorage is as light-weight than cookies (lighter-weight, arguably), though, so that should be enough, no? If you really need cookie information you can always call postMessage and ask for it. Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. / Jonas
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
On Thu, 13 Nov 2008, Jonas Sicking wrote: Honestly I'm not really sure why the spec says that you need a list at all, other than maybe to talk about GC (which i've many times mentioned I think the spec should not need to define). I remembered what it was that I was trying to remember the last time we spoke about this -- the case that the spec is trying to define that I don't know how to define in any other way is the case where a worker has no non-GC'ed communication mechanisms with the outside world (e.g. the Worker object is dropped and GC'ed on the outside, there are no message handlers set up, and there are no other ports around), but the worker has a timer set up [1] to do some work that can have side-effects. Without defining when GC happens, there would be a detectable way to tell that the worker went away. We want such workers to keep going until the document that they were associated with is navigated away. That's what the text in the spec is doing. (It also defines when a worker should be suspended, for similar reasons.) I don't really see how we can do away with this without interop issues. [1] or a pending XHR, or a pending database transaction response, or... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers feedback
On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers feedback
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. - a
Re: [whatwg] video tag : loop for ever
On Thu, Nov 13, 2008 at 6:56 PM, Ian Hickson [EMAIL PROTECTED] wrote: If I have missed a key point, please do let me know. It's quite possible that I missed something when reading this thread as it was quite long and had a lot of repetition. Sounds good to me. / Jonas
[whatwg] Deprecating small, b ?
The small element represents small print [...] The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance [...] Both definitions seems rather presentational (contrasting, for example, the new semantic definition for the i element) and could also be realized by use of span elements. To me these look like the last remnants of the font element. So why are these elements retained ? Greetings, Nils
Re: [whatwg] video tag: pixel aspect ratio
I agree that incorrectly encoded videos are annoying, but I don't think we should have this attribute at all because I don't think it passes the will it be commonly used smell test. I am also afraid that it will difficult to use correctly, since you frequently have to use clean aperture in conjunction with pixel aspect ratio to get the correct display size. For the videos we're talking about, just getting near the right ratio is probably all we can ask for -- we're not talking about professional video data here. We're talking misencoded YouTube videos where an embedder wants to fix the most egregious error before showing his friends the cat jumping off the side of the pool or something. I agree that this is just a hack attribute, and I agree that it isn't going to be widely used. But I think it will be used enough to justify its existence. There are a surprisingly large number of misencoded videos on the Web, and plenty of people who care. I don't see how people who can't properly transcode (the majority of users I guess), will know on the other hand which aspect ratio to use to fix the problem (or even think about using this fix). Maybe there'll be some JS libraries around to do this automatically on the fly, but I don't see how this would ever be consistent or reliable. The real fix would need to be done in their workflow or tool they use. Also wouldn't services like YouTube be able to auto-detect such videos and resize them anyway (uploaded QT movies should have all the necessary info embedded for instance, but even if it is missing, you can likely assume that a 720x480 video should be resized to 640x480 before being served)? And the suggested hack is not even really usable: if you have a video coming from a NTSC DV source as 720x480 improperly transcoded to say MP4 720x480 square pixels, using the theoretical 10:11 pixel aspect ratio will _not_ make it look right: it needs to be clipped to 704x480 first. Pixel aspect ratio has a precise meaning in the video world, and using it outside of clean aperture does not make a lot of sense... At the same time, saying that pixel ratio is intentionally ill-defined because we don't *really* want people to use it is also quite confusing. If we start going in this direction, then img should have a dpi attribute so you can hack around images uploaded at dpi 72 ;) In any case, if this attribute really needs to be present, we should rename it at the minimum (picking a term from the professional video world requires taking the constraints that come with it), maybe displayRatio or something? Pierre-Olivier Latour - [EMAIL PROTECTED] Rich Media Team - Apple, Inc.
[whatwg] Sending MessagePorts after they have started
Hi All, It is currently possible (I think) to send a port through postMessage after the port was started. This makes sending ports across processes (such as to an iframe or worker living in a different process) pretty painful to implement. It also makes it hard to define without causing race conditions. What you have to do: Say that port B and port C are entangled and live in separate processes, lets call the processes 2 and 3. Both ports are started. A message is posted to port B which means that it should arrive to port C. The implementation sends a IPC message from process 2 to process 3 that says that a message should be fired on C. However before that IPC message is processed, script decides to forward port C to another iframe, this iframe is running in process 4. The implementation sends a IPC message to process 4 saying that a new port should be created, port D, and that it should be entangled with port B living in process 2. It also sends a IPC message to process 2 saying that port B is now entangled with port D in process 4. Process 3 now receives the IPC message from process 2 saying that a message should be fired on port C. The implementation now has to send an IPC message to process 4 saying to fire the message to port D instead. Process 2 now receives the IPC message from process 3 saying that port B is now entangled with port D in process 4 and updates its data structures to reflect that. The script in process 2 now calls postMessage on port B to send a second message. The implementation sends an IPC message to process 4 saying that a message event should be fired on port D. This IPC message arrives immediately to process 4 saying that port D should fire a message event. However the implementation must now detect that this message was received out-of-order (through for example a ID counter in the sending port) and queue it. Finally the IPC message from process 3 to process 4 arrives about the first message event and both message events can be fired in order. Things get hairier if somewhere along this the scripts decided to forward port B in process 2 to an iframe run by process 1. Then you have to proxy the 'port B is now entangled with port D in process 4' message on to process 1 which means that even more messages can go to the wrong place and be proxied to the correct process and port. There are alternative implementation strategies. The simplest one is probably to never tell the other end when a port is moved, instead set up a permanent proxy and forward all message through the full chain of processes that the ports have passed through. Another strategy is to require that each message is acknowledged and resend messages if a port end was retangled before the message got processed. It's also hard to specify this without race conditions since you have to deal with the situation that a port has been retangled after a message was queued for it to fire against the port. To fix all this I propose that if a port has been started, we don't allow it to be passed to postMessage. If that is done an exception is thrown. This way ports can queue all outgoing messages until they receive word that the other port has been opened. Then messages can always be sent to a known address that will never move. I can't think of any use case that this would disable. You still have to deal with getting the information about that a port has been opened and where it lives to the other port. But this is somewhat simpler. / Jonas
Re: [whatwg] Workers feedback
On Thu, 13 Nov 2008, Jonas Sicking wrote: Aaron Boodman wrote: On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. It returns the script's URL, not the page's. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Reworking the media load() algorithm so that it tries more than one video
On Thu, 16 Oct 2008, Robert O'Callahan wrote: I am proposing changing the spec to make the load() not select a resource. Instead, load() would immediately return, and the user agent would then asynchronously try each resource that it might otherwise use in turn, firing a single loadstart event at the start, lots of progress events, and then a loadedmetadata or error event depending on how things go. That sounds good. I've now done this. This is a pretty big change. I'm sure I've screwed something up in the process. Implementors! Please let me know if you see anything newly broken with loading resources! Thanks. :-) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers feedback
Aaron Boodman wrote: On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. / Jonas
Re: [whatwg] Workers feedback
Ian Hickson wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Aaron Boodman wrote: On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Actually, i think we should remove the location accessor as well. I can't think of a common enough use case that warrants an explicit API. You can always transfer the data through postMessage. I added that one becase Aaron asked for it. Aaron? I think it's useful. Obviously it's not totally necessary. What are the use cases? Also note that we can't use it with shared workers since they can be connected to several pages from different uris. It returns the script's URL, not the page's. Oh?! Then I understand even less what the use case is. This is something that doesn't exist for script and i've never heard anyone ask for it (granted, that is not proof that no one wants it). / Jonas
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Ian Hickson wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: Honestly I'm not really sure why the spec says that you need a list at all, other than maybe to talk about GC (which i've many times mentioned I think the spec should not need to define). I remembered what it was that I was trying to remember the last time we spoke about this -- the case that the spec is trying to define that I don't know how to define in any other way is the case where a worker has no non-GC'ed communication mechanisms with the outside world (e.g. the Worker object is dropped and GC'ed on the outside, there are no message handlers set up, and there are no other ports around), but the worker has a timer set up [1] to do some work that can have side-effects. Without defining when GC happens, there would be a detectable way to tell that the worker went away. We want such workers to keep going until the document that they were associated with is navigated away. That's what the text in the spec is doing. (It also defines when a worker should be suspended, for similar reasons.) I don't really see how we can do away with this without interop issues. It sounds to me like simply saying: setTimout(handler, ms): When called will schedule a event 'ms' milliseconds after the function is called. When the event fires 'handler' is called. would make it a bug to not fire the event and produce any side effects that it would have. For exactly the same reasons that canceling a pending XHR request would be a bug. (The above is obviously a far simplification of setTimeout) / Jonas
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
On Thu, 13 Nov 2008, Jonas Sicking wrote: I don't really see how we can do away with this without interop issues. It sounds to me like simply saying: setTimout(handler, ms): When called will schedule a event 'ms' milliseconds after the function is called. When the event fires 'handler' is called. would make it a bug to not fire the event and produce any side effects that it would have. For exactly the same reasons that canceling a pending XHR request would be a bug. The above would also mean that the timeout would fire even after the document has been closed, which is not what we want. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Ian Hickson wrote: On Thu, 13 Nov 2008, Jonas Sicking wrote: I don't really see how we can do away with this without interop issues. It sounds to me like simply saying: setTimout(handler, ms): When called will schedule a event 'ms' milliseconds after the function is called. When the event fires 'handler' is called. would make it a bug to not fire the event and produce any side effects that it would have. For exactly the same reasons that canceling a pending XHR request would be a bug. The above would also mean that the timeout would fire even after the document has been closed, which is not what we want. True, you also need to define that when a document is closed pending timers and in-progress XHR requests, are canceled. Don't know enough to have an opinion on DB transactions. / Jonas
