| 00:12 | <Lachy> | if scoped stylesheets were changed to be evaluated only in the context of the scoped tree, rather than the whole document, the :scope would still be useful because it allows you to select the scope element and it's children with the child combinator |
| 00:13 | <Lachy> | it would only remove the need for :scope when used in conjunction with the descendant combinator, in most cases. |
| 00:14 | <annevk> | if selectors would work that way re-using :root makes even more sense |
| 00:14 | <annevk> | and the sole advantage of :root as I demonstrated in my e-mail goes away |
| 00:14 | <annevk> | advantage of :scope, I should say |
| 00:14 | <Lachy> | maybe we could allow for both options |
| 00:15 | <annevk> | over engineering? |
| 00:15 | <Lachy> | no |
| 00:15 | <annevk> | yes |
| 00:15 | <Lachy> | no |
| 00:15 | <Hixie> | :root should match the root element and that's all |
| 00:15 | <Hixie> | don't overload it with random other functionality |
| 00:16 | <othermaciej> | I don't see why changing the meaning of :root in some cases is better than adding :scope for those use cases |
| 00:16 | <Lachy> | there were a few cases where the ancestor elements outside the scope are useful, as I gave some examples of already |
| 00:16 | <othermaciej> | it would still need a change to the Selectors spec |
| 00:17 | <othermaciej> | and unless there are cases where you want to refer to either the document root or the scope node interchangeably depending on context, it doesn't seem helpful to use a single pseudo-class for both |
| 00:17 | <annevk> | I was just saying that if we change selectors to not match outside the subtree it would be over engineering to also keep the current solution |
| 00:17 | <Lachy> | new version of the spec http://lists.w3.org/Archives/Public/www-archive/2008Jul/att-0025/Overview.html |
| 00:17 | <Lachy> | using :scope now |
| 00:17 | <jcranmer> | whee, discussion of the scoped-stylesheet debate |
| 00:17 | <annevk> | but since the current solution is better it seems good to not introduce the one where you need to change selectors |
| 00:19 | <Hixie> | selectors should match outside the scoped subtree imho |
| 00:19 | <annevk> | doing anything else changes selectors |
| 00:20 | <annevk> | afaict |
| 00:20 | <jcranmer> | I still don't see why |
| 00:20 | <annevk> | because selectors are run in the context of a document |
| 00:20 | <jcranmer> | well, the idea of scoping is that you're explicitly limiting scope |
| 00:21 | <Hixie> | the element doesn't suddenly lose its parent just because you are scoped to it |
| 00:21 | <jcranmer> | which to me implicitly limits context as well |
| 00:21 | <Hixie> | if you style elements that are inside <Aside> elements, they should still have those styles even if the <Aside> is outside your scope |
| 00:21 | <jcranmer> | it doesn't limit it, it just makes it portable |
| 00:21 | <jcranmer> | s/limit it/loses its parent/ |
| 00:22 | <Lachy> | I think they should apply to the whole document too. It should be possible to take a stylesheet that normally applies to a whole document, but then just restrict the set of elements it applies to, without altering which elements match. |
| 00:22 | <Lachy> | that's only possible with matching outside of the subtree is true. |
| 00:23 | <jcranmer> | AFAICT, the primary use case is for when the author of a subsection does not have access to the style of the whole page |
| 00:23 | <jcranmer> | which makes matching outside the scope pointless |
| 00:23 | <annevk> | my use case was including some local styles for a blog entry |
| 00:23 | <jcranmer> | right |
| 00:23 | <Lachy> | but, there does seem to be some demand for the other situation too, and so maybe if those use cases are justified, an attribute on the style selement could specify whether the context was the whole document or the subtree |
| 00:24 | <annevk> | i do have access to the whole page :) |
| 00:24 | <jcranmer> | I'd end up having to <root of scope> <rest of selector> the entire thing |
| 00:24 | <annevk> | jcranmer, why? |
| 00:24 | <jcranmer> | annevk: to limit the styles properly of course |
| 00:25 | <Lachy> | only when you're using the descendant selector |
| 00:25 | <annevk> | jcranmer, if you needed to do that the scoped attribute would have no effect, but it does |
| 00:25 | <jcranmer> | of course, I think we can sidestep the entire argument by having the author point out which model he would like to use |
| 00:26 | jcranmer | heads to supper |
| 00:26 | <Lachy> | <style scoped context="document"> or <... context="scope"> |
| 00:26 | <annevk> | not changing selectors seems the most straightforward path and is already how, e.g. getElementsByClassName works |
| 00:27 | <annevk> | well, the definition, hah, it doesn't actually matter of course there :/ |
| 00:30 | <Hixie> | with :scope you don't need any of this |
| 00:30 | <Hixie> | you can just stick :Scope on the front of every selector and be done with it |
| 00:31 | <annevk> | yup |
| 00:38 | <Lachy> | Hixie, yeah, I agree, but people are complaining about having to do that. |
| 00:39 | <annevk> | there's always people who disagree with something |
| 00:39 | <Lachy> | I know, but I don't like that. Why can't everyone just agree with everything I say? |
| 00:40 | annevk | shrugs |
| 00:42 | <Hixie> | Lachy: "waah" |
| 00:42 | <Hixie> | Lachy: "I have considered your feedback but decided to not do this for v1." |
| 00:43 | <Lachy> | what? |
| 00:43 | <Lachy> | where did I say that? |
| 00:44 | <Hixie> | you didn't |
| 00:44 | <Hixie> | i'm saying that's how you should respond |
| 00:44 | <Lachy> | oh |
| 00:44 | <Hixie> | in response to the "waah" from people |
| 00:45 | <Lachy> | ok. |
| 00:46 | <Lachy> | for some issues, it's just not worth it though. It's sometimes easier to give in than to continue putting up with whinging. |
| 00:46 | <Hixie> | no |
| 00:46 | <Hixie> | never let whinging make you make suboptimal decisions |
| 00:46 | <Lachy> | ok |
| 00:47 | <Hixie> | as spec writers people for the next 100 years or more are going to rely on our decisions |
| 00:47 | <takkaria> | Hixie: btw, on your comments about hsivonen's parser earlier, if the tokeniser was only switched into case-preserving mode "in foreign content", I don't think there'd be much if any performance hit |
| 00:47 | <Hixie> | that is a huge responsibility |
| 00:47 | <Lachy> | Hixie, that's right. So I have to be sure that I'm making the right decisions. |
| 00:48 | <Lachy> | sometimes that's difficult. |
| 00:48 | <Hixie> | often :-) |
| 00:48 | <Hixie> | takkaria: maybe, i don't know what his parser looks like |
| 00:49 | <takkaria> | I've looked at it, and that seems to be the case |
| 00:49 | <takkaria> | not that would make the SVG people happy anyway |
| 00:56 | <Hixie> | why does no software handle multigigabyte files well |
| 00:56 | <Hixie> | sigh |
| 00:57 | <Lachy> | what kind of file do you have that is multigigabyte, unless it's video or something? |
| 00:57 | <Hixie> | .csv file |
| 01:05 | jcranmer | points out the simple solution again |
| 01:05 | <Hixie> | there's a simple solution to dealing with multigigabyte csv files? :-) |
| 01:06 | <takkaria> | is fgets() not enough? |
| 01:07 | <jcranmer> | Hixie: no, to the scoped style discussion |
| 01:07 | <jcranmer> | make an attribute on the element and let authors decide |
| 01:07 | <Hixie> | adding an attribute seems like bad design |
| 01:07 | <Hixie> | why is :Scope not enough? |
| 01:08 | <jcranmer> | because I'd prepend it to every selector then |
| 01:08 | <Hixie> | takkaria: writing little scripts to process the data is what i've done, but it sucks that i can't use real spreadsheet tools |
| 01:08 | <Hixie> | jcranmer: so? |
| 01:08 | <jcranmer> | the key word there is "every" |
| 01:08 | <jcranmer> | if there's boilerplate for everything, then maybe the decision should be looked at again |
| 01:08 | <Hixie> | jcranmer: to be honest i don't believe you :-) i mean, i believe that you think you would, but i think in practice you wouldn't at all end up doing that. |
| 01:09 | <Hixie> | jcranmer: for example if you have styles for elements that are in links, i don't see why it matters if the link is inside the scope or not |
| 01:09 | <takkaria> | Hixie: I'd have thought excel would manage it, but if not, then I don't know what hope any other spreadsheet tools have |
| 01:09 | <Hixie> | i don't have office |
| 01:10 | <jcranmer> | OOo? |
| 01:10 | <Hixie> | but i doubt either numbers or the openoffice spreadsheet tool can handle a few dozen megabytes, let alone more than 2 gigabytes |
| 01:11 | <jcranmer> | I'm going out on a limb here and guessing you're not using FAT |
| 01:11 | <Hixie> | um no |
| 01:11 | <Hixie> | NFS |
| 01:11 | <jcranmer> | hmm, how could I guess ;-) |
| 01:11 | <Hixie> | does anyone still use FAT? |
| 01:11 | <roc> | yes |
| 01:11 | <Hixie> | wow |
| 01:11 | <roc> | All CF cards |
| 01:11 | <jcranmer> | my old, *old* computer |
| 01:12 | <jcranmer> | anyone who uses floppies |
| 01:12 | <roc> | so *you* still use FAT |
| 01:12 | <Hixie> | i don't have any CF cards |
| 01:12 | <jcranmer> | roc: I don't use that computer |
| 01:12 | <jcranmer> | it's my parents |
| 01:12 | <jcranmer> | ' |
| 01:12 | takkaria | uses CF cards :( |
| 01:13 | <roc> | I bet most USB keys use FAT too |
| 01:13 | <Hixie> | don't have any of those either :-) |
| 01:13 | <roc> | and probably Sony's memory sticks |
| 01:13 | <roc> | and SD |
| 01:13 | <Hixie> | SD? |
| 01:13 | <roc> | if you don't have a digital camera, then I'll be impressed |
| 01:13 | <jcranmer> | Hixie: what about your brain? |
| 01:13 | <Hixie> | i don't have a digital camera |
| 01:13 | <takkaria> | you have an iPod, but if you're a Mac user, you probably don't use FAT there either... |
| 01:14 | <roc> | now yu |
| 01:14 | <Hixie> | yeah my ipod is HFS+, i believe |
| 01:14 | <roc> | now you're just showing off |
| 01:14 | <Hixie> | i have an iSight and an external iSight |
| 01:14 | <Hixie> | but those don't have storage |
| 01:14 | jcranmer | would not be suprised if an appliance in Hixie's house used FAT |
| 01:15 | <jcranmer> | if not, I'm sure the computers at the airport checkin line use them |
| 01:15 | <jcranmer> | maybe the ATM as well |
| 01:15 | <Hixie> | i expect my girlfriend's camera uses flash, but i don't know what storage it uses (she uses USB to get the data off) |
| 01:15 | <Hixie> | i used an ATM once in the last 12 months. :-) |
| 01:16 | Hixie | recently discovered this when he audited his bank records to make his budget for the coming months |
| 01:16 | <Hixie> | er, s/uses flash/uses FAT/ |
| 01:16 | <jcranmer> | hmm, Hixie said nothing about flying... |
| 01:16 | <Hixie> | i flew three times in the last year, i think |
| 01:16 | <Hixie> | well, three times two |
| 01:17 | <Hixie> | and the experiecne is worse each time |
| 01:18 | <Hixie> | anyway |
| 01:18 | Hixie | goes back to defining Pipes |
| 01:18 | <Hixie> | if anyone can find a better name for the PipeEnd object, let me know |
| 01:19 | <othermaciej> | MessagePort |
| 01:19 | <roc> | yeah Port |
| 01:19 | <Hixie> | ooo |
| 01:20 | <othermaciej> | (I like that better as general terminology than Pipe too) |
| 01:21 | <roc> | it's useful to be able to talk about the connection itself |
| 01:21 | <roc> | although usually the connection isn't exposed as a first-class object |
| 01:22 | <annevk> | only the bridge between the "ports" is exposed |
| 01:22 | <Hixie> | right now only hte ports are exposed |
| 01:22 | <Hixie> | but you create them as ap air |
| 01:22 | <Hixie> | as a pair |
| 01:23 | <Hixie> | so there is an object that represents a pair of ports when they are first created |
| 01:23 | <Hixie> | called a Pipe right now |
| 01:24 | <roc> | Unix pipes block on write if the reader isn't reading |
| 01:24 | <roc> | if you're doing something asynchronous then you might want a more general term for clarity |
| 01:24 | <Hixie> | no blocking here |
| 01:24 | <Hixie> | yeah |
| 01:24 | <Hixie> | i've renamed PipeEnd to MessagePort |
| 01:25 | <Hixie> | what terminology goes with Ports for the object that holds two ports? |
| 01:25 | <roc> | MessageChannel for the connection object? |
| 01:25 | <Hixie> | that works |
| 01:26 | <Hixie> | or just Channel |
| 01:26 | <Hixie> | since this is the constructor you'll call |
| 01:26 | <Hixie> | var x = new Channel(); |
| 01:26 | <Hixie> | x.port1; x.port2; |
| 01:27 | <Hixie> | maybe Channel and ChannelPort? Rather than Channel and MessagePort? |
| 01:28 | <othermaciej> | ChannelPort seems less clear |
| 01:28 | <Hixie> | yeah |
| 01:28 | <Hixie> | though frankly, few people will deal with the name MessagePort |
| 01:29 | <roc> | I'd use MessageChannel to be honest |
| 01:30 | <othermaciej> | Channel does seem a bit more vague |
| 01:30 | <Hixie> | MessageChannel it is |
| 01:30 | <annevk> | MessageChannel is also more consistent with postMessage |
| 01:31 | <Hixie> | ok well this terminology is much better now |
| 01:31 | <Hixie> | thanks |
| 08:56 | <Hixie> | if you have a channel with ports 1 and 2 |
| 08:56 | <Hixie> | and you try to send port2 down port1 |
| 08:56 | <Hixie> | it should obviously fail |
| 08:56 | <Hixie> | because the semantics of that are just crazy weird |
| 08:56 | <Hixie> | but if you send port1 down port1 |
| 08:56 | <Hixie> | should it also throw? |
| 08:57 | <Hixie> | it would be equivalent to having a rope and throwing one end to the other end |
| 08:57 | <Hixie> | "here's a channel!" |
| 08:57 | <Hixie> | pretty useless, since why wouldn't you just create a new MessageChannel() for yourself |
| 08:57 | <Hixie> | i would guess most cases of port1 going down port1 will be mistakes |
| 08:57 | <Hixie> | so it makes sense to fail big |
| 08:57 | <Hixie> | at the point of error |
| 08:58 | <Hixie> | instead of having hard-to-debug problems later |
| 09:16 | gDashiva | is getting postMessage endpoint-passing flashbacks |
| 09:18 | <Hixie> | gDashiva: hm? |
| 09:18 | <gDashiva> | It just sounds so similar |
| 09:19 | <Hixie> | it is more than similar |
| 09:19 | <Hixie> | it's the same thing |
| 09:19 | <gDashiva> | That would explain it then |
| 09:25 | <Hixie> | roc and mjs came up with the better names |
| 09:25 | <Hixie> | pipe become message channel |
| 09:25 | <Hixie> | and end point and pipe end become message port |
| 09:26 | <Hixie> | s/become/became/ |
| 09:26 | <Hixie> | i'm doing dvorak-layout typos while typing on a qwerty keyboard |
| 09:26 | <Hixie> | that's freaky |
| 09:27 | <Hixie> | that suggests that when i do typos, i'm hitting the keys my brain intended to hit |
| 09:27 | <Hixie> | but that my brain doesn't have a good idea of what keys to hit, and that it makes mistakes based on locality of the keyboard layout |
| 09:27 | <Hixie> | but that the mistakes it makes aren't necessarily related to the keyboard layout it is actually typing on |
| 09:41 | <Lachy> | http://blogs.msdn.com/ie/archive/2008/07/14/ie8-ajax-navigation.aspx |
| 10:02 | <Hixie> | wish they'd say what they actually implemented :-) |
| 10:04 | <Hixie> | just the hashchanged event apparently |
| 10:18 | <gDashiva> | The third comment makes me sad. |
| 10:26 | <Hixie> | is that the one about how their markup "sucls"? |
| 10:26 | <Hixie> | sucks |
| 10:26 | <Hixie> | rather |
| 10:26 | <Hixie> | it made me sad too |
| 10:28 | <MikeSmith> | I'm pretty sure this is picture of the guy who wrote that comment: |
| 10:28 | <MikeSmith> | http://upload.wikimedia.org/wikipedia/en/7/79/The_Simpsons-Jeff_Albertson.png |
| 10:29 | <annevk> | you wouldn't say |
| 10:32 | <Lachy> | when did Comic Book Guy get named Jeff Albertson? |
| 10:33 | <Lachy> | oh, apparently way back in 2005. |
| 10:35 | <Lachy> | that comment did have a point about the DOCTYPE though. The PDF contains "<!DOCTYPE>" |
| 10:38 | <annevk> | Hixie, in MessagePort various definitions and references have mismatching titles, at least onmessage and ownerWindow |
| 10:39 | <Hixie> | fixed onmessage a while back |
| 10:39 | <Hixie> | fixed ownerWindow just now, thanks |
| 10:48 | <annevk> | Hmm, isn't another reason that the tokenizer is made case-insensitive so that xmlns and xmlns:* attributes can be used outside the context of the subtree? |
| 10:54 | <takkaria> | heh, "Having <svg:a> be interpreted by a legacy user agent as <html:a> is perhaps not that critical, you can even add a 'src' attribute to have the link work in both contexts, so it can be used as a sort of fallback. |
| 10:57 | <annevk> | Hixie, just hit refresh to verify, seems the second ownerWindow ref is still wrong |
| 10:57 | <gDashiva> | takkaria: svg in html, appendix C |
| 11:00 | <Hixie> | anne: should be ok now |
| 11:00 | <annevk> | lol, few days before the E3 Sony says it can't be bothered by Nintendo and now they announce all kinds of competitive features |
| 11:32 | <annevk> | what is DOMFrameContentLoaded? |
| 11:32 | <annevk> | hmm, seems to be some Firefox event |
| 11:32 | <Hixie> | ok, i defined postMessage(m, p, o) |
| 11:33 | <Hixie> | let me know if it's separate enoug |
| 11:33 | <Hixie> | h |
| 11:36 | <Hixie> | ok what else do i need for workers |
| 11:36 | <Hixie> | i guess i need to split Window |
| 11:37 | <Hixie> | i love how everyone was saying "use a separate spec!" |
| 11:37 | <Hixie> | but i've basically ended up having to do tons of work in html5 proper anyway |
| 11:38 | <annevk> | Hixie, message is not dispatched on an element and is not dispatched on document either (re: introduction) |
| 11:39 | <annevk> | Hixie, I think the latest is that it's dispatched on window |
| 11:39 | <Hixie> | hm i just moved that example up |
| 11:39 | <Hixie> | i didn't edit it :-) |
| 11:40 | <annevk> | that might explain things :p |
| 11:41 | <Hixie> | fixed |
| 11:46 | <annevk> | yeah, for Workers you need to split Window into main thread only and multithreaded functionality |
| 11:47 | <annevk> | but that would've been the case if you kept it in the spec or not |
| 11:47 | <Hixie> | sure |
| 11:48 | <Hixie> | i'm just amused that the workers spec is going to be about one page long of non-boilerplate material |
| 11:48 | <Hixie> | but that the total number of changes will have been dozens of pages |
| 12:13 | <annevk> | lol, http://www.p01.org/releases/DHTML_contests/files/DEFENDER_of_the_favicon/ |
| 12:17 | <Hixie> | wow he is so completely disqualified from ever suggesting anything to html5 again :-P |
| 12:21 | <Hixie> | ok Window is split |
| 12:21 | <Hixie> | that was easy |
| 12:21 | <Lachy> | that's clever, but really difficult to play |
| 12:22 | <Lachy> | even if I zoom my screen right in to see it, it's just not enough pixels |
| 12:23 | <Philip`> | I can't play the game without the page scrolling annoyingly |
| 12:23 | <annevk> | Hixie, why is frames not under self-reference? |
| 12:23 | <Hixie> | because workers can't have frames |
| 12:24 | <Lachy> | Philip`, make your window bigger so it doesn't have scroll bars |
| 12:24 | <annevk> | Hixie, but frames is just a useless alias for self and window |
| 12:24 | <annevk> | Hixie, it's nothing special |
| 12:24 | <Hixie> | indeed |
| 12:24 | <Hixie> | so why have it on workers? |
| 12:24 | <annevk> | why have self on workers? |
| 12:24 | <Philip`> | Lachy: I'd have to make the window bigger than my screen, which is kind of awkward |
| 12:25 | <Hixie> | annevk: because it makes more sense than window |
| 12:25 | <Lachy> | Philip`, get a bigger screen with a higher resolution. |
| 12:25 | <Philip`> | Lachy: That's expensive :-p |
| 12:26 | <Lachy> | it's essential that you have a screen resolution of 1920x1200 so you can play a game of 16x16px |
| 12:26 | <gDashiva> | If I reduced my resolution to 640x480, maybe I'd be able to see what was happening |
| 12:26 | <annevk> | Hixie, still most people use window and don't use self |
| 12:26 | <virtuelv> | Philip`: you can use WASD to move instead -- won't scroll then |
| 12:26 | <Philip`> | If you're on OS X, just use the ctrl(?) + mouse-wheel thing to zoom in on the play area |
| 12:27 | <gDashiva> | annevk: If anything, self is often shadowed to work around "this" voodoo |
| 12:27 | <Lachy> | Philip`, yes |
| 12:27 | <Philip`> | virtuelv: It does scroll, since those keys make Opera select links on the page |
| 12:27 | <virtuelv> | Philip`: disable one-key shortcuts |
| 12:27 | <Hixie> | annevk: right, that's why i'm keeping window too |
| 12:27 | <Lachy> | Philip`, write a user style sheet that hides everything else on the page |
| 12:28 | <Philip`> | virtuelv: But then shift-G stops working, which is why I turned on one-key shortcuts in the first place |
| 12:28 | <Lachy> | what does Shift+G do? |
| 12:28 | <virtuelv> | Lachy: toggle images |
| 12:28 | <Philip`> | Lachy: Toggle stylesheets |
| 12:28 | <virtuelv> | ah, stylesheets it was |
| 12:29 | <virtuelv> | Philip`: you could always reassign keys to your own liking :) |
| 12:29 | <Philip`> | virtuelv: I'm far too lazy for that |
| 12:29 | <Philip`> | and far too indecisive |
| 12:30 | <Lachy> | Philip`, just temporarily disable it. I had to disable "Search for text when I start typing" so I could play it too. |
| 12:30 | <Philip`> | I can cope with preference checkboxes, but if I get offered a million actions to map onto any permutation of a million keystrokes, I get too confused to do anything at all :-( |
| 12:31 | <Lachy> | Philip`, yeah, it's a well known problem that Opera's keyboard shortcut configuration is too complex |
| 16:05 | <billyjack> | interesting to see that Kaazing guys will be doing a session on the WebSocket interface at AjaxWorld |
| 16:05 | <billyjack> | http://www.sys-con.com/read/609412_p.htm |
| 19:01 | <csarven-> | http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html |
| 20:45 | <tusho_> | Huh. Why is the sanitizer allowing <p> in <h1>?! |
| 21:08 | <gsnedders> | People are crazy. |
| 21:09 | <gsnedders> | This is what defining how people have made the real world has taught me. |
| 21:09 | <Hixie> | no kiding |
| 21:09 | <Hixie> | kidding |
| 21:10 | <gsnedders> | Content-Type: text/html;image/gif;image/jpeg; Charset=iso-8859-1;text/javascript |
| 21:11 | <jmb> | gsnedders: nice! which one is it really? :) |
| 21:11 | <gsnedders> | jmb: Dunno, haven't looked :) |
| 21:12 | <gsnedders> | text/html, it's http://www.ecsrefining.com/ |
| 21:13 | <gsnedders> | you just ignore most of the stuff as invalid parameters, I expect |
| 21:13 | <Hixie> | do browsers get the right charset? |
| 21:13 | <Hixie> | does html5? |
| 21:14 | <gsnedders> | It looks to be pure US-ACSII the actual page |
| 21:14 | <gsnedders> | It should be treated as windows-1252 |
| 21:15 | <gsnedders> | So, yeah, HTML 5 and everything copes fine |
| 21:16 | <gsnedders> | text/html; charSet=gb2312;charset=ISO-8859-1 makes me more interested |
| 21:17 | <gsnedders> | That is gb2312 really |
| 21:17 | <gsnedders> | http://www.mediachina.net/ FWIW |
| 22:25 | <Hixie> | what's better. window.closing becoming true when the thread is being shut down, or window.active becoming false when the thread is being shut down. |
| 22:25 | <Hixie> | the latter allows for while(active) { ... } |
| 22:26 | <Hixie> | the former allws for if (closing) return; |
| 22:28 | <othermaciej> | will the cancellation design make it meaningful to even ask? |
| 22:29 | <Hixie> | i figure when the thread gets canceled we should set this flag, fire an unload event at the next available opportunity, and wait a couple of seconds to see if the thread shuts down cleanly, and if it doesn't, kill it forcibly. |
| 22:29 | <Hixie> | seems better to at least give the thread a chance to clean up after itself rather than just always killing it forcibly |
| 22:31 | <othermaciej> | POSIX has the notion of registering cancellation cleanup handlers |
| 22:31 | <othermaciej> | I'm not sure if "run for a few more seconds" is a useful design point |
| 22:31 | <Hixie> | that's what the unload event is for |
| 22:31 | <othermaciej> | particularly if those few seconds might be in blocking I/O (assuming blocking IO operations are cancellation points) |
| 22:32 | <Hixie> | POSIX doesn't have to worry about the cancelation cleanup handlers trying to do blocking I/O or trying to solve checkers on a 64x64 board. |
| 22:32 | <Hixie> | we do. |
| 22:32 | <Hixie> | i don't see how we can _not_ have a timeout |
| 22:32 | <Hixie> | since we have to basically assume the workers are hostile |
| 22:33 | <othermaciej> | I guess what I'm saying is, I think it would be better to terminate normal flow execution of the thread (if any) immediately, fire the cancellation-related event, and then have a timeout |
| 22:33 | <othermaciej> | having the thread keep running means you need two timeouts |
| 22:33 | <Hixie> | that's a bit extreme, you might be in the middle of a 10ms transaction when you get terminated |
| 22:34 | <othermaciej> | and sprinkling your code with "am I cancelled" checks would be ugly and in some cases not really possible anyway |
| 22:34 | <Hixie> | i guess i don't mind having two timeouts if you think we need it, but i certainly think we need at least to give the main code the opportunity to run to completion before we kill it |
| 22:34 | <othermaciej> | that misses the point of cancellation |
| 22:35 | <othermaciej> | if the main code could be trusted to run to completion in reasonable time, you could just send the thread a message to kill itself |
| 22:35 | <Hixie> | i think you're assuming that workers are going to always be running non-stop code |
| 22:35 | <othermaciej> | no, I'm assuming they might be |
| 22:35 | <othermaciej> | cancellation is most important for the case where they are |
| 22:36 | <othermaciej> | if they aren't you can use messages to establish a protocol to stop the thread's activity |
| 22:36 | <Hixie> | i'm imagining many workers will be mostly idle and will be mostly doing very short event handler type code -- receive an event, store the data in the database. And for those cases, you absolutely never want to abort in the middle of the handler, since that might corrupt your database or lose data. |
| 22:36 | <othermaciej> | aborting would not corrupt your database because they have transactional semantics |
| 22:37 | <othermaciej> | the database operation must either complete or roll back |
| 22:37 | <Hixie> | assumign they do it right, sure |
| 22:37 | <Hixie> | you'll still lose data |
| 22:37 | <Hixie> | i don't see any reason not to give those handlers time to complete, they won't be taking long anyway. |
| 22:38 | <othermaciej> | if you can afford to wait for them, then you can just postMessage to the thread and ask it to stop further activity |
| 22:38 | <othermaciej> | if you absolutely want to guarantee that any pending I/O finishes, you have to do that anyway |
| 22:38 | <othermaciej> | a timeout gives you the worst of both worlds |
| 22:39 | <othermaciej> | no guarantee the I/O will complete, and no guarantee the thread stops promptly |
| 22:39 | <Hixie> | that's what the unload event is for |
| 22:39 | <othermaciej> | if you need to register an event handler to ensure that cancellation is clean, then there's no benefit to your main code continuing to run |
| 22:39 | <Hixie> | i don't understand what you are proposing or why |
| 22:42 | <othermaciej> | I'm proposing that cancellation stops whatever is executing right away, and invokes any registered cancellation handlers with a timeout limit |
| 22:43 | <Hixie> | how does that not cause dataloss in the case of a thread having just received a message asking it to store data? |
| 22:43 | <othermaciej> | and I explained why - letting the main code continue to run defeats the most important use case for cancellation, which is a thread that's busy doing a long computation |
| 22:43 | <othermaciej> | the other way causes data loss too, if the message has not been dispatched yet |
| 22:44 | <othermaciej> | (unless the thread registers a cancellation handler, but I guess there is no way to explicitly drain the message queue) |
| 22:44 | <Hixie> | unload would be added to the queue of events, it would be the last fired event. |
| 22:44 | <othermaciej> | you shouldn't cancel a thread if you sent it a message that you actually need to be processed |
| 22:44 | <Hixie> | the author isn't the one canceling the thread |
| 22:44 | <Hixie> | the user is |
| 22:44 | <othermaciej> | you should ask it to finish itself instead |
| 22:45 | <othermaciej> | so this is for leaving the page, not for an explicit cancellation API? |
| 22:45 | <Hixie> | we're talking about the user closing the window or something like that, yes |
| 22:47 | <othermaciej> | well for code on the main thread, there's no specific timeout for currently running code defined, and unload gets to run with no specific timeout defined |
| 22:47 | <othermaciej> | (as well as beforeunload which has the opportunity to cancel the close / leave operation) |
| 22:47 | <Hixie> | the spec doesn't define a timeout, but there is a timeout |
| 22:48 | <Hixie> | and arguably the spec should define that (though the precise number would be up to the UA) |
| 22:48 | <othermaciej> | in the case of Safari the timeout would be the general slow script timeout |
| 22:48 | <Hixie> | right |
| 22:49 | <othermaciej> | anyway I see that this is a trickier design problem than what I thought you were talking about (API for thread cancellation) |
| 22:50 | <Hixie> | ah ok |
| 22:50 | <Hixie> | the API for thread cancellation is simple |
| 22:50 | <Hixie> | just send an event and be done with it |
| 22:50 | <Hixie> | i don't know that i'll even add anything explicit for that |
| 22:50 | <othermaciej> | you need to be able to cancel a thread that is blocked or in the middle of computation |
| 22:51 | <Hixie> | maybe just the "close()" method of the message port objects |
| 22:51 | <othermaciej> | postMessage conventions can't do that |
| 22:51 | <Hixie> | why? |
| 22:51 | <Hixie> | i mean, why is that necessary |
| 22:53 | <othermaciej> | to avoid wasting CPU cycles if you fire off long-running computation that turns out to be unnecessary |
| 22:54 | <Hixie> | hm |
| 22:54 | <othermaciej> | and to make it slightly easier not to make all your threads be runaways (otherwise you have to set up a message handler in the thread to cancel all timers and pending I/O when asked to stop, seems like a needless pain) |
| 22:55 | <Hixie> | well if all the channels to a worker get closed, you kill the thread as if the user had killed it |
| 22:55 | <Hixie> | though you'd still want to use a timeout to allow the thread to empty it's message queue |
| 22:55 | <Hixie> | its |
| 22:56 | <othermaciej> | closing all channels as implicit termination is a bit weak (you have to keep track of all channels you may have vended) |
| 22:57 | <othermaciej> | and also I guess counts on the worker object itself not being a message target, or else you have to make sure to drop all refs and let it get GC'd to really kill it |
| 22:57 | <Hixie> | isn't that a good thing? why would you want to kill a worker if some other frame has a handle to it? especially given that that could mean the thread dying while someone is talkign to it |
| 22:58 | <Hixie> | well the way i'm currently speccing it, there is no worker object on the outside |
| 22:58 | <Hixie> | only the channels |
| 22:58 | <Hixie> | creating a worker gets you a channel to that worker |
| 22:58 | <othermaciej> | I see |
| 22:59 | <othermaciej> | is there a way to copy the channel (so that you have multiple copies which independently need to be closed)? |
| 22:59 | <Hixie> | if the worker is named, you can get multiple independent windows (from the same origin) getting channels to a single worker |
| 22:59 | <Hixie> | and since you can send a port down a channel, you can associate multiple channels with a worker, yes |
| 23:00 | <Hixie> | they're not the same channel, just different channels that have one end owned by the worker |
| 23:01 | <othermaciej> | I don't think open channels controlling the lifecycle makes sense |
| 23:01 | <Hixie> | why not? |
| 23:01 | <othermaciej> | having an open channel wouldn't keep a Window alive presumably, if that window is otherwise closed |
| 23:02 | <Hixie> | if a window closes, or has its session history traversed, channels to that window have their other end temporarily deactivated |
| 23:02 | <Hixie> | (the channels get permanently deactivated when the window is garbage collected) |
| 23:19 | <annevk> | Hixie, is Workers going to define a new database and local storage API and such? |
