| 01:57 | <Hixie> | aboodman, sicking: personally i think of the proposals i've seen i like what's in the spec best, but i'll spec whatever you end up agreeing on if you do come to an agreeemnt that's good |
| 01:58 | <Hixie> | aboodman, sicking: however i'd recommend against compromising on things just to get agreement, you should definitely think that whatever you agree with is the best if you agree to it, not just agree for the sake of getting progress |
| 01:58 | <Hixie> | that way lies compromise-driven madness |
| 02:00 | <sicking> | yay madness! |
| 02:07 | <othermaciej> | Hixie: are you willing to compromise on your stance against compromise-driven madness? |
| 02:07 | <Hixie> | no :-) |
| 02:07 | <Hixie> | though i'll spec whatever gets implemented, so there are ways to override me :-) |
| 02:09 | <Dashiva> | othermaciej: He'll have to wait for the committee to finish evaluating |
| 07:07 | <aboodman> | hi weinig, just posted that mail i promised |
| 07:07 | <weinig> | aboodman: sweet! |
| 07:10 | <aboodman> | argh, please replace all occurences of 'sendMessage()' with 'postMessage()'. I keep mixing up the gears and html5 names. |
| 09:02 | <zcorpan> | hmm both safari and firefox seem crash prone if you throw 10 video elements at them in the same page |
| 09:08 | <olliej> | zcorpan: could you file a bug at bugs.webkit.org? :D |
| 09:20 | <hsivonen> | zcorpan: would be good to have your test case on b.m.o, too :-) |
| 09:26 | <doublec> | zcorpan, what version of firefox? |
| 09:31 | <zcorpan> | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081031 Minefield/3.1b2pre |
| 09:36 | <zcorpan> | olliej, hsivonen: see http://simon.html5.org/test/html/semantics/video/loading-demos/ |
| 09:36 | <olliej> | zcorpan: is it first click safe? |
| 09:37 | <zcorpan> | yes it's a dir page |
| 09:37 | <zcorpan> | don't have time right now to file bugs though sorry |
| 09:45 | <roc> | it's not crashing for me, although it isn't really working either |
| 09:46 | <roc> | oh, I think I hit the HTTP connection limit or someting |
| 09:46 | <roc> | now they're all playing |
| 09:46 | <roc> | poorly |
| 09:46 | <doublec> | yes I see the same |
| 09:57 | <zcorpan> | roc: it doesn't crash for m,e every time |
| 09:59 | <zcorpan> | firefox actually first showed a gray area instead of the page when i tried to load 002.html, and then did the same for any other page, then when i tried to quit firefox it crashed. i pressed the restart firefox button and then it showed the uninstall minefield dialog (and restarted firefox) |
| 09:59 | <zcorpan> | very weird |
| 10:01 | <roc> | mmm |
| 10:52 | <Philip`> | http://radar.barackobama.com/ - wow, it's a fancy animated map thing that isn't Flash - I think that's the first time I've ever seen one that isn't |
| 10:52 | <Philip`> | The layout's a bit broken in Opera, but it's the thought that counts |
| 10:53 | Philip` | presumes it's using jQuery for animatedness |
| 11:08 | <zcorpan> | i presume this is spam http://forums.whatwg.org/viewtopic.php?t=4025 |
| 11:09 | <zcorpan> | same ip |
| 11:10 | <hsivonen> | are robocall in the U.S. legal for political advertising? I thought they were made illegal for telemarketing in general. |
| 11:10 | <Philip`> | http://www.google.com/search?q=%22I+need+to+ask+you+guyz+a+question%22 |
| 11:15 | <Philip`> | hsivonen: I believe they are legal, purely on the basis that if they weren't then a lot of people would have complained very loudly about it, and I haven't heard anyone complaining that they're anything other than rude and irritating |
| 11:19 | <Philip`> | (Also, Wikipedia says lots of states have different rules for political organisations than commercial ones, for automated phone calls) |
| 11:20 | <Philip`> | (That combination of methods of proof-by-not-hearing-anyone-else-claim-it's-untrue and proof-by-Wikipedia is clearly infallible) |
| 11:22 | Philip` | discovers http://uncyclopedia.wikia.com/wiki/Proof as a useful repository of such proof methods |
| 12:23 | <jcranmer> | Philip`: I love Proof-by-Wikipedia |
| 12:28 | <jcranmer> | I suppose that was a dumb idea |
| 12:29 | <jcranmer> | if I choose to reply to this email, I will probably embroil myself in a debate as to whether or not the HTML specification should be roughly as precise as a law |
| 12:30 | jcranmer | chooses not to respond |
| 12:30 | hsivonen | notes that law has very different precision in different countries |
| 12:31 | <hsivonen> | some countries assume you #include "commonsense.h" |
| 12:33 | <jcranmer> | jcranmer $ locate commonsense.h |
| 12:33 | <jcranmer> | /usr/include/bitbucket/commonsense.h |
| 12:33 | <jcranmer> | jcranmer $ ls -l /usr/include/bitbucket/commonsense.h |
| 12:35 | <jcranmer> | -r--r--r-- 1 root root 18 2008-01-01 00:00 /usr/include/bitbucket/commonsense.h -> /dev/null |
| 12:35 | <jcranmer> | :-( |
| 12:38 | Philip` | wonders which email jcranmer is referring to |
| 12:40 | <jcranmer> | Philip`: off-list |
| 12:40 | <Philip`> | Ah |
| 14:55 | <zcorpan> | Hixie: you probably want to hide the "watch for updates" box for print media |
| 14:56 | <Philip`> | What if you print onto dynamic e-paper? |
| 14:59 | <zcorpan> | then it still overlaps the other text |
| 15:00 | <zcorpan> | and dynamic e-paper might well use the screen media instead |
| 15:00 | <zcorpan> | s/and/or/ |
| 15:01 | <zcorpan> | i wonder why the status boxes aren't in the print version |
| 15:07 | <zcorpan> | "???? (KUROSAWA Takeshi)" says the pdf |
| 15:27 | <Philip`> | The link underlining in http://yaml.org/spec/1.2/#Introduction looks disturbingly weird to me |
| 15:28 | <Philip`> | It looks like they intentionally made it look that way, but I can't imagine why |
| 16:06 | <jcranmer> | egads |
| 16:07 | <jcranmer> | anyone here remember Dmitry Turin, or did he only do stuff on the CSS lists? |
| 16:08 | <jcranmer> | (well, I'm sure that many core people here watch both lists anyways) |
| 16:08 | <Philip`> | He was on public-html too |
| 16:08 | <jcranmer> | ah |
| 16:08 | <Philip`> | Sadly he seems to have been absent lately |
| 16:08 | <jcranmer> | well, consider him back as of today |
| 16:09 | <jcranmer> | he just made some posts to the mozilla newsgroups of all places |
| 16:09 | <Philip`> | Excellent! |
| 16:09 | <jcranmer> | Subject: HTML6 budget |
| 16:09 | <jcranmer> | it goes downhill from there, IMO |
| 16:09 | <Philip`> | That's a very promising start |
| 16:10 | <Philip`> | I liked it when he gave a link to a 200-slide Powerpoint presentation |
| 16:26 | <MikeSmith> | Good to hear that Dmitry Turin is back |
| 16:26 | <MikeSmith> | I was worried that he might have given up on his dreams |
| 16:28 | <jcranmer> | I'm not in the mood to deal with him in this case |
| 16:29 | <jcranmer> | I'm already embroiled in three or four long threads |
| 16:31 | <Philip`> | As far as I can tell, nobody has extracted any value from discussions with him on public-html, so it seems safe to ignore him |
| 16:31 | <jcranmer> | I definitely will do that |
| 16:34 | <MikeSmith> | I think in many cases Dmitry is not necessarily expecting a response anyway |
| 16:34 | <Philip`> | (People have suggested that he should try identifying problems and use cases rather than just presenting a complete solution without explaining why it's worthwhile, but I haven't seen him follow that advice yet) |
| 16:35 | <jcranmer> | I think he is |
| 16:35 | <jcranmer> | expecting |
| 16:35 | <Dashiva> | Philip`: He saves us all the work of going through those phases by giving us the complete solution |
| 16:36 | <Philip`> | (He does seem to have put a lot of effort into his work, so it'd be nice if he could redirect that effort towards something that would actually be practical) |
| 16:36 | <hsivonen> | mozilla.dev.planning it seems |
| 16:36 | <jcranmer> | Philip`: "He needs concrete budget. So i'm asking you to estimate and say, how much will it cost." |
| 16:37 | <jcranmer> | he wants a response, it seems |
| 16:37 | <MikeSmith> | I don't think Dmitry's interested in mundane things like examining and documenting use cases or investigating whether there may be some spec or technology that already solves the problems he's created complete solutions for |
| 16:37 | <jcranmer> | MikeSmith: of course not |
| 16:38 | <Philip`> | jcranmer: Did you mean s/Philip`/MikeSmith/? |
| 16:38 | <jcranmer> | Philip`: oh, right |
| 16:38 | <jcranmer> | sorry |
| 16:38 | <jcranmer> | MikeSmith: it only works with his new solutions |
| 16:38 | <Philip`> | Apology accepted |
| 16:38 | <Philip`> | :-p |
| 16:38 | <MikeSmith> | jcranmer: right |
| 16:39 | <MikeSmith> | He wants to build the whole complete rocket ship to the moon, from scratch |
| 16:39 | <Philip`> | MikeSmith: I think he is aware of existing technology - e.g. he looked at the existing XPath technology, and then changed the syntax a bit so that he liked it more |
| 16:39 | <MikeSmith> | Philip`: OK |
| 16:40 | <Philip`> | or at least gave a few examples of what the syntax ought to look like |
| 16:40 | <Philip`> | which is totally enough to justify making a new XML path selector standard |
| 16:43 | <Philip`> | MikeSmith: Hmm, how long ago did people realise that making a moon rocket would require a lot of work? I think it was some Jules Verne thing where one guy built one himself, whereas nowadays everyone realises you need giant corporations or government organisations to do it, but I have no idea when people switched from one view to the other... |
| 16:44 | <MikeSmith> | Philip`: me neither.. |
| 16:44 | <Philip`> | MikeSmith: Alas :-( |
| 16:55 | <MikeSmith> | related to that "how long ago.." question - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/016985.html seems sort of relevant |
| 16:55 | <MikeSmith> | the part where Mike Schinkel writes, "The irony is that if TBL had gotten this kind of resistance"... |
| 17:01 | <MikeSmith> | and Hixie points out that TimBL actually implemented what he spec'ed |
| 17:05 | <Dashiva> | "This is very much a case of empowering serendipity" <- What? |
| 17:07 | <MikeSmith> | the thing with Dmitry Turin -- and I guess a good number of others as well -- is that they spin these grand plans without any intention of actually implementing them. The expect that somebody else will implement it for them. |
| 17:07 | <MikeSmith> | the word empowering should be banned from all discussions. anybody who uses it should receive a thrubbing |
| 17:07 | <Dashiva> | And that everyone will use them once implemented. |
| 17:08 | Philip` | made an entry for the ICFP contest where you had to write an AI bot that would navigate a map and find food and push competing robots out of the way, and called it Serendipity because that was the only way it would ever actually find any food |
| 17:08 | <MikeSmith> | heh |
| 17:09 | <Dashiva> | Oh, that quote. "what does your robot do, sam?" "it collects data about the surrounding environment, then discards it and drives into walls" |
| 17:11 | <Philip`> | It would be funnier if it weren't so true |
| 17:12 | Philip` | once made a robot which triggered its own reset switch every time it hit an obstacle |
| 17:13 | <MikeSmith> | robots shouldn't do practical stuff -- the should to crazy, unpredictable stuff, and make strange sounds |
| 17:14 | <MikeSmith> | http://en.wikipedia.org/wiki/Dorkbot |
| 17:14 | <Philip`> | Also, it's unfortunate that the power of Lego motors is greater than the strength of the Lego chassis in which I usually put them |
| 17:14 | <MikeSmith> | "people doing strange things with electricity" |
| 17:15 | <MikeSmith> | Philip`: out-of-control torque is a great thing to watch |
| 17:15 | <erlehmann> | Philip`: pixxx! |
| 17:16 | <Philip`> | Attaching four Lego motors (powered from a 12V adapater) to a half-meter S shape made of Lego monorail track is great fun, particularly when mounted on top of a combat robot |
| 17:17 | <Philip`> | *adapter |
| 17:17 | <Philip`> | You can get quite a lot of kinetic energy out of them |
| 17:19 | <erlehmann> | wat |
| 17:20 | <erlehmann> | back to biz - are there any deprecated items in the HTML5 spec ? |
| 17:21 | <Philip`> | erlehmann: No - you're either allowed to write things, or not allowed to |
| 17:21 | <erlehmann> | also, i believe that section 4.8.2.1.3 should contain strong wording to use CSS |
| 17:21 | <zcorpan> | erlehmann: why? |
| 17:21 | <Philip`> | (though of course you can still write things that you're not allowed to, and they'll still work) |
| 17:22 | <Philip`> | (for some understanding of 'work') |
| 17:22 | <erlehmann> | CSS3 content replacement would probably make the section obsolete anyway |
| 17:23 | <zcorpan> | erlehmann: why would you use css for logos and icons? |
| 17:25 | <erlehmann> | zcorpan: i already do, if they conver no additional semantic info. for navlists as presented in the spec i just change the "list icon" (how is it called). |
| 17:25 | <zcorpan> | erlehmann: you didn't answer my question though :) |
| 17:25 | <erlehmann> | common icons usually are deco that can be replaced without changing semantics, therefore i use CSS. |
| 17:26 | <zcorpan> | ah |
| 17:26 | <erlehmann> | like doing a web site in tango style, then switching over to aqua look. |
| 17:26 | <erlehmann> | most icons have the same purposes as colors - merely being stylistic elements |
| 17:27 | <zcorpan> | i don't quite agree -- icons are closer to the content than the color scheme |
| 17:27 | <zcorpan> | pretty much like italics vs font face |
| 17:28 | <erlehmann> | well yes, but they usually convey semantics that are already there. |
| 17:29 | <Philip`> | The semantics usually aren't there unless you specifically add class names as hooks for the images |
| 17:29 | <erlehmann> | consider a change of a corporations' logo. on the corporation website, it is purely stylistic. on a web site discussing design and typography the logo is semantic content. |
| 17:30 | <jcranmer> | ... must ... resist ... troll ... posting |
| 17:30 | <jcranmer> | ... |
| 17:30 | <zcorpan> | it's not just stylistic -- it's important for users to recognize where they are |
| 17:31 | <Philip`> | If you're changing the logo, you'd just overwrite /images/logo.gif and it doesn't matter how you're referencing it in a page :-) |
| 17:31 | <Philip`> | Uh oh |
| 17:32 | <Philip`> | Dmitry came back to public-html |
| 17:45 | <jcranmer> | oh, I just realized why I didn't see that post... I subscribe to all but public-html :-) |
| 18:17 | <erlehmann> | Philip`: that proves that the image by itself has no semantic meaning, doesn't it ? |
| 18:17 | <erlehmann> | which was my point, btw |
| 19:15 | Philip` | wonders why people are being so rude to Pentasis |
| 19:15 | <jcranmer> | Philip`: his assertion that specs shouldn't be written by/for browser vendors? |
| 19:19 | <Philip`> | jcranmer: That's a reason to strongly disagree, particularly when he's making those claims within the context of the WHATWG which is fundamentally designed in opposition to his claims |
| 19:19 | <Philip`> | but it doesn't seem like a reason to explicitly laugh at him or to say "Now GTFO my web" |
| 19:22 | <jcranmer> | Philip`: I haven't seen any of the recent messages, so I can't riposte |
| 19:29 | <erlehmann> | Philip`: the point is that his criticism is pointless. he claims that WHATWG has "not the right" to evolve HTML. fine, fine, go make another standard ! what pentasis does is akin to flaming on the KDE mailing list that they should use GTK. |
| 19:42 | <jcranmer> | I wonder what Hixie's position is |
| 20:16 | <Hixie> | my position on the guy who said "GTFO my web" is that i told him that was unacceptable; if he does it again he'll get banned for a week |
| 20:20 | <erlehmann> | Hixie: oh, that would be me. |
| 20:20 | <erlehmann> | i'll watch my output, then. |
| 20:45 | <gsnedders> | oh hell |
| 20:46 | <gsnedders> | /. commenhs are now worse than digg at tines |
| 20:46 | <jcranmer> | weren't they always? |
| 20:46 | <doublec> | this the theora thread? |
| 20:48 | <gsnedders> | doublec: yep. totally not reading what I'm saying |
| 20:48 | <gsnedders> | jcranmer: Rarely. |
| 20:50 | <gsnedders> | Apparently I'm suggesting Ogg has patent problems. I'm not. I'm saying Theora's patent status beyond On2's patents is unknown. |
| 20:50 | <Philip`> | But when talking about patents, being unknown is a problem |
| 20:51 | <gsnedders> | But Ogg != Theora. |
| 20:53 | <Philip`> | Ah |
| 20:53 | <Philip`> | But they're close enough :-p |
| 20:55 | <gsnedders> | The guy who is arguing with me knows the difference, but thinks I am saying Ogg has problems and can't believe he's arguing with someone who thinks that. |
| 20:55 | <Dashiva> | Why don't we just encode the video as sound |
| 20:55 | <Dashiva> | That way we're safe! |
| 20:56 | <Philip`> | Dashiva: That won't work - it wouldn't be accessible to deaf people |
| 20:56 | <gsnedders> | :D |
| 20:57 | <Dashiva> | They could convert back to video. It's all just waves anyway |
| 20:57 | <Philip`> | Ah, cunning |
| 20:58 | <jcranmer> | gsnedders: I see what you mean |
| 20:58 | <Philip`> | Of course, somebody will have patented the audio/video conversion algorithm |
| 20:59 | <gsnedders> | jcranmer: /. comments in general or the thread specifically? |
| 21:02 | <jcranmer> | gsnedders: specific thread |
| 21:02 | <gsnedders> | Can I be bothered to write a long comment? |
| 21:03 | <gsnedders> | http://slashdot.org/comments.pl?threshold=-1&commentsort=0&mode=nested&cid=25625761 |
| 21:03 | <gsnedders> | hmm |
| 21:03 | jcranmer | attempts to gauge how much will make it through |
| 21:04 | <gsnedders> | that URI doesn't work |
| 21:05 | <jcranmer> | Hixie: good thing I did some discussion off-list, then :-) |
| 21:08 | <gsnedders> | I had a discussion like it at TPAC. Some people were taking it up with timbl, who grabbed me (or rather called me, first by another name beginning with g, then correctly) as a passing HTML WG member. |
| 21:09 | <gsnedders> | Got some history about HTML's relation to SGML |
| 21:10 | <Dashiva> | "You look like a suitable decoy" |
| 21:10 | <gsnedders> | :D |
| 21:28 | <aboodman> | sicking, othermaciej_: i wanted to make sure that you saw i resumed the thread about workers as promised. |
| 21:28 | <othermaciej_> | aboodman: I did |
| 21:28 | <sicking> | aboodman, yeah, will comment |
| 21:29 | <sicking> | aboodman, it's a little fuzzy on what new API you are proposing though |
| 21:29 | <sicking> | aboodman, such as, is there an implicit call to 'connect' when a shared worker is created? |
| 21:29 | <aboodman> | sicking: yes. should i follow up with the IDL? |
| 21:30 | <sicking> | aboodman, i'll comment first |
| 21:31 | <aboodman> | sicking: i misread your question. there is no implicit connect() call. callers must always call connect() explicitly. |
| 21:31 | <sicking> | aboodman, ah, that's what i suspected, though you don't mention that change |
| 21:32 | <aboodman> | sicking: my apologies, i wasn't sure what would be the least lossy way to communicate my ideas. |
| 21:50 | <sicking> | othermaciej: I don't see your reply yet on the whatwg list btw |
| 21:53 | <othermaciej_> | I did not reply |
| 21:53 | <othermaciej_> | I did see the thread |
| 21:55 | <othermaciej_> | I agree with Alexey's reply |
| 21:55 | <othermaciej_> | and also the general sentiment that it would be good to reduce the number of interfaces to the messaging mechanism |
| 22:12 | <sicking> | othermaciej_, aboodman: my concern with forcing connect() to be called on a dedicated worker is that it makes the simple case so complicated for the user. I've detailed in a response |
| 22:13 | <sicking> | othermaciej_, aboodman: in any case this is something that we need to decide on very soon. We're freezing today, but i might be able to get changes done for a few more days |
| 22:20 | <othermaciej> | sicking: it doesn't seem that much more complicated to me, particularly considering that Workers are an advanced feature in the first place |
| 22:21 | <othermaciej> | sicking: I tend to think overall API simplicity is more important here than optimizing the simple case |
| 22:21 | <sicking> | othermaciej, even with the nested event handlers? |
| 22:22 | <sicking> | othermaciej, I do think there is value in making the simple case simpler, if it's the common use case |
| 22:23 | Hixie | thought what we had today was pretty simple as it was |
| 22:23 | <sicking> | othermaciej, creating a single API that fits all use cases doesn't always yield the simplest API for any of them |
| 22:23 | <othermaciej> | sicking: so you are really concerned about one extra line of code in 4-5 line code sequences? |
| 22:23 | sicking | agrees with Hixie |
| 22:23 | <othermaciej> | I have to admit I don't care much about this either way, other than wanting a resolution |
| 22:24 | <othermaciej> | but I agree with aboodman that having three different ways to do worker-related messaging overall seems like a mess |
| 22:24 | <sicking> | othermaciej, mostly the nested functions, with two different events in scope are complicated |
| 22:24 | <Hixie> | i don't really see that we have three ways |
| 22:24 | <Hixie> | they're all the same way |
| 22:24 | <sicking> | well, startConversaion is just a convinence method, not really a new mechanism. I'm fine with dropping that |
| 22:25 | <Hixie> | and startConversation was only added in response to aaron's request :-) |
| 22:25 | <sicking> | ultimately there is only one communication mechanism: postMessage |
| 22:26 | <othermaciej> | I have a hard time getting worked up about it either way |
| 22:26 | <othermaciej> | like I said |
| 22:26 | <sicking> | with aarons proposal you'll actually always have to use two mechanisms, connect() and postMessage() |
| 22:26 | <othermaciej> | I think this is an advanced feature in any case |
| 22:26 | <sicking> | i mostly agree, i'm ok with either, though it might be hard to get postMessage dropped from FF3.1 at this point |
| 22:27 | <othermaciej> | I'd be more concerned about the complexity of determining worker lifetime if anything |
| 22:27 | <othermaciej> | although that's more a concern for implementations than an API issue |
| 22:28 | <Hixie> | i'm ok with whatever API people want, but in the face of apathy i'm strongly in favour of the status quo |
| 22:28 | <Hixie> | (if the arguments aren't convincing, as, imho, in this case) |
| 22:50 | <aboodman> | Jonas, hixie, I don't see how you think there is only one mechanism. |
| 22:51 | <aboodman> | Maybe we are having a terminology problem. |
| 22:51 | <sicking> | aboodman, the only way you can send data is through 'postMessage' |
| 22:51 | <aboodman> | yes, but the method is located on different objects. |
| 22:51 | <aboodman> | and must be initialized differently. |
| 22:51 | <Hixie> | the only mechanism is the message channel mechanism |
| 22:51 | <Hixie> | and it's initialised automatically whenever possible |
| 22:53 | <aboodman> | so again, in the case of dedicated workers, you have worker.postMessage(). In the case of shared workers, you have worker.port.postMessage(). |
| 22:53 | <aboodman> | the inside is also different. |
| 22:54 | <sicking> | i guess if you consider them different or not is a matter of definition. But they aren't *that* different IMHO |
| 22:55 | <aboodman> | well it is different. a developer must remember that in the case of dedicated workers you can call postMessage() on the worker object, but not on shared workers. |
| 22:55 | <aboodman> | I don't see why this should be the case. |
| 22:55 | <Hixie> | in the case of shared workers, it can't be optimised further since there are multiple ports |
| 22:56 | <Hixie> | it's not worker.port.postMessage() |
| 22:56 | <Hixie> | it's just myPort.postMessage() |
| 22:56 | <Hixie> | oh you mean on the outside |
| 22:56 | <Hixie> | not the inside |
| 22:56 | <sicking> | aboodman, making all cases as complicated as the most complicated isn't neccesarily a win IMHO |
| 22:56 | <sicking> | necessarily |
| 22:56 | <aboodman> | Hixie: yes, i was talking about the outside. |
| 22:56 | <Hixie> | we could remove the .port on the shared worker case, but that would be an oversimplification of the API, imho |
| 22:57 | <Hixie> | i don't understand why we'd want to expose the port only on one side |
| 22:57 | <aboodman> | Hixie: what difference would that make? |
| 22:57 | <Hixie> | that would be even mroe confusing |
| 22:57 | <aboodman> | Hixie: why would that be more confusing? |
| 22:58 | <sicking> | Hixie, the advantage of not having an implicit connect() is that you remove the correlation one-page-one-connection |
| 22:58 | <Hixie> | the answer to the question "Is this a MessagePort or something special?" would be "well..." |
| 22:58 | <sicking> | Hixie, so if you have some service that does server-db access for example and you want several such connections from a single page, you act the same way for each such connection |
| 22:59 | <sicking> | Hixie, and on the inside you don't care about what connection is from a new page and what is a new connection from an already existing page |
| 22:59 | <aboodman> | Since people are not that thrilled with startConversation/connect, I can make an alternate proposal that also collapses the shared worker/dedicated worker duality. |
| 22:59 | <aboodman> | but does not have startConversation |
| 23:00 | <aboodman> | OUTSIDE: var worker = new SharedWorker("foo.js", "foo"); worker.postMessage("ping"); |
| 23:00 | <sicking> | aboodman, i do like the separation between shared and dedicated. Because it allows us to keep the dedicated simpler than the shared one inheritly can be |
| 23:01 | <aboodman> | INSIDE: onmessage = function(e) { e.messagePort.sendMessage("pong") } |
| 23:01 | <Hixie> | look i don't mind going back to the generic mechanism we used to have, where shared and dedicated workers were indistinguishable, and there was exactly one mechanism |
| 23:01 | <Hixie> | but nobody liked that |
| 23:01 | <Hixie> | i don't really understand the point of trying to get that withotu actually getting it |
| 23:02 | <Hixie> | i don't have a problem with startConversation() |
| 23:02 | <Hixie> | i think it's fine |
| 23:03 | <aboodman> | Hixie, I think that my last proposal is almost exactly the same as your initial one, except that there is a first class Worker object. |
| 23:03 | <aboodman> | But the Worker object, does not have any postMessage() related apis on it. |
| 23:03 | <Hixie> | how does this address sicking's original complaints? |
| 23:04 | <Hixie> | (for a while the spec did have an api with a first class worker object with a pipe on it, btw) |
| 23:04 | <aboodman> | it doesn't, I was just clarifying that basically I am in favor of going back to your original design with a few minor alterations. |
| 23:05 | <Hixie> | i'm not, sicking said he wouldn't implement it :-) |
| 23:05 | <aboodman> | gotcha. |
| 23:07 | <aboodman> | sicking: I think that if we get rid of connect/startConveration then we can combine the two interfaces w/o adding any code at all to the DedicatedWorker case. I think this would be a win. |
| 23:07 | <Hixie> | why? |
| 23:07 | <Hixie> | (just curious) |
| 23:07 | <Hixie> | (not saying there's no reason it'd be a win) |
| 23:08 | <aboodman> | the same reason code reuse is usually good |
| 23:08 | <sicking> | aboodman, well, you'll have a weird implicit port created on the inside that isn't reachable until someone posts |
| 23:08 | <aboodman> | less opportunity for bugs. |
| 23:08 | <sicking> | aboodman, i know someone (maciej?) wasn't too exited about not being able to post out until someone had posted in |
| 23:08 | <Hixie> | are we talking inside or outside here? i'm confused. what are you saying you want to change exactly? |
| 23:09 | <Hixie> | there are use cases for posting in both directions first, we shouldn't preclude that in either case |
| 23:09 | <aboodman> | I don't think we need to preclude posting from outwardly first. |
| 23:09 | <aboodman> | s/from// |
| 23:09 | <sicking> | aboodman, how would you post out then? |
| 23:09 | <Hixie> | what are you saying you want to change exactly? relative to the current spec |
| 23:10 | <sicking> | aboodman, i.e. what object would you call postMessage on? |
| 23:10 | <aboodman> | in both the dedicated and shared case you'd call postmessage on the worker object. |
| 23:10 | <sicking> | aboodman, what would that send a message to on the shared worker |
| 23:10 | <sicking> | ? |
| 23:10 | <aboodman> | getting to that :) |
| 23:10 | <aboodman> | on the inside there are onconnect and onmessage events |
| 23:12 | <aboodman> | in both events you get a "port" (maybe not exactly the same thing currently called MessagePort) in the event object which allows you to talk back to the outer interface that sent you a message or connected. |
| 23:13 | <aboodman> | note: there is no global postMessage() or port object on the inside of workers for either the dedicated or shared case. |
| 23:13 | <sicking> | aboodman, 'in the event'? if you want to post outward first there is no event, no? |
| 23:13 | <sicking> | oh |
| 23:13 | <aboodman> | sicking: you get onconnect |
| 23:13 | <aboodman> | which is basically onload |
| 23:13 | <aboodman> | in the case of dedicated workers |
| 23:15 | <sicking> | hm |
| 23:15 | <sicking> | it still looks to me like you're adding complexity to the dedicated worker solely for the case of making it more similar to the shared one |
| 23:16 | <aboodman> | i have reduced the amount of added complexity to only the case where the worker wants to send messages outward first. |
| 23:17 | <sicking> | sure, you're adding just a little complexiy, but still seems like it's only for the sake of making it more similar to the dedicated worker |
| 23:18 | <sicking> | hm, btw, where do messages appear? |
| 23:18 | <aboodman> | i suppose. the global complexity is lower though. it seems like a great trade-off to me. |
| 23:18 | <sicking> | if i do w = new Worker(...); w.postMessage('foo'); |
| 23:18 | <sicking> | where do i catch that on the inside? |
| 23:18 | <aboodman> | global onmessage event |
| 23:19 | <sicking> | so there's a global onmessage but no global postMessage? |
| 23:19 | <aboodman> | yes. |
| 23:19 | <aboodman> | that is the proposal. |
| 23:19 | <aboodman> | which makes sense functionally -- the relationship between workers and clients is 1 to many. |
| 23:20 | <sicking> | that seems unexpected given that we don't have that anywhere else |
| 23:21 | <aboodman> | not sure what to tell you. it doesn't seem weird to me. |
| 23:22 | <sicking> | i still prefer what we currently have (possibly modulo removing startConversaion and the implicit call to connect() on shared workers) |
| 23:22 | <sicking> | aboodman, but do post to the list and see what others feel |
| 23:22 | <aboodman> | sicking: how do you think that shared workers should talk to the outside? |
| 23:24 | <sicking> | aboodman, if we remove implicit connect()? |
| 23:25 | <aboodman> | sicking: yeah, i don't understand what your proposal is for shared workers in general. |
| 23:26 | <aboodman> | the current spec for them doesn't make a lot of sense to me |
| 23:26 | <sicking> | start with as now |
| 23:26 | <sicking> | add a connect() method |
| 23:26 | <sicking> | remove .port |
| 23:26 | <aboodman> | i see. |
| 23:26 | <sicking> | when connect() is called a port is returned |
| 23:27 | <sicking> | and a 'connect' event is fired inside the worker |
| 23:27 | <sicking> | the connect event object holds the port for the other end of the channel |
| 23:27 | <aboodman> | i think part of the disconnect (hah!) is that you think connect() is a feature of shared workers only. i think it is useful for all workers. i actually think it is _less_ useful for shared workers, since you can get basically the same effect by just creating multiple instances of the shared worker. |
| 23:27 | <aboodman> | so if it isn't on dedicated workers, i wouldn't put it on shared workers |
| 23:28 | <sicking> | hmm |
| 23:28 | <sicking> | interesting idea |
| 23:28 | <sicking> | so just talking about shared workers for a sec |
| 23:28 | <Hixie> | wait, what's connect)? |
| 23:28 | <Hixie> | connect()? |
| 23:29 | <sicking> | Hixie, in my described solution above it raises a connect event inside the worker with a port, and then returns the other port |
| 23:29 | <sicking> | aboodman, so just talking about shared workers for a sec, how would you do communication with a shared worker? |
| 23:30 | <aboodman> | i think that what i proposed above would be my ideal solution |
| 23:30 | <sicking> | so there is a worker.postMessage |
| 23:30 | <aboodman> | var worker = new SharedWorker("foo.js", "foo"); worker.postMessage("ping"); ||| onmessage = function(e) { e.messagePort.postMessage("pong"); } |
| 23:33 | <sicking> | aboodman, (still just talking about shared workers). So that looks nice, except the disconnect between onmessage/no-postMessage. So how about this: take that proposal, except that when a new shared worker is instantiated a 'connect' message is raised. That message contains a port that has postMessage/onmessage |
| 23:34 | <Hixie> | sicking: why would we want that? |
| 23:34 | <sicking> | Hixie, want what? |
| 23:34 | <aboodman> | sicking: i prefer it w/o special cases for dedicated workers. i don't think the lack of a global postMessage() is a big deal. |
| 23:34 | <Hixie> | connect() |
| 23:34 | <sicking> | Hixie, there seems to have been some disconnect about that |
| 23:34 | <Hixie> | yeah sorry i'm not really paying much attention here, supposed to be on vacation :-) |
| 23:35 | <Hixie> | watching electrion coverage and replying to two e-mails at the same time too |
| 23:37 | <sicking> | aboodman, still feels like doing that is just adding complexity to the dedicated worker for the sole purpose of having it more similar to the shared one |
| 23:37 | <sicking> | aboodman, dedicated workers are by nature simpler, why not let them be |
| 23:38 | <sicking> | aboodman, with this new proposal the difference is minimal |
| 23:39 | <sicking> | aboodman, no difference on the outside, and on the inside the only difference is that shared workers have to listen to 'connect' to get new incoming communication channels |
| 23:39 | <sicking> | aboodman, whereas the dedicated worker simply lets the global scope be the communication channel |
| 23:40 | <aboodman> | sicking: yes, it is a big improvement. i don't think the remaining differences are that big a deal. |
| 23:40 | <aboodman> | i still think it would be better if the inner interfaces were the same, but this difference won't bother me that much if it is what browser supported. |
| 23:41 | <sicking> | aboodman, i do really like to keep onmessage/postMessage in sync |
| 23:42 | <aboodman> | <shrug> ok. |
| 23:42 | <sicking> | wanna mail to the list or should I? |
| 23:42 | <aboodman> | i will |
| 23:42 | <sicking> | cool, do bring up both proposals |
| 23:42 | <aboodman> | which ones? |
| 23:43 | <aboodman> | oh you mean the two that are very close together. |
| 23:43 | <sicking> | right |
| 23:43 | <aboodman> | ok, sure. |
| 23:43 | <sicking> | thanks |
| 23:43 | <aboodman> | on the bright side, i believe this would mean no changes to things you've already implemented. |
| 23:43 | <sicking> | yup |
| 23:44 | <sicking> | that'd be the case with either of them |