| 00:25 | <TabAtkins> | heycam: ! |
| 00:25 | <heycam> | TabAtkins, hi :) |
| 00:25 | <TabAtkins> | [MapClass]? |
| 00:25 | <heycam> | yes yes, I know :) |
| 00:25 | <TabAtkins> | ^_^ |
| 00:25 | heycam | still has a few days left in the week to make good |
| 00:26 | <heycam> | I saw the thread on www-style |
| 00:26 | <heycam> | (so I guess the implementation work is why you'd like it looked at soon) |
| 00:31 | <TabAtkins> | Yup! |
| 00:32 | <TabAtkins> | Was talking with the implementor a few minutes ago. |
| 00:32 | <heycam> | cool |
| 00:52 | <TabAtkins> | Hixie: Yo, are the W3C versions of PostMessage/SSE/WebWorkers/etc all still accurate? Are they genned off of the current WHATWG spec, or what? |
| 02:58 | <annevk> | TabAtkins: sequence<Node> won't have .find and .findAll on it, so I think arv is wrong |
| 03:24 | <Hixie> | TabAtkins: i think the ones in dev.w3.org are, but i wouldn't bet on it |
| 03:24 | <Hixie> | TabAtkins: certainly the canonical material as far as i'm concerned is the material in whatwg.org/c |
| 06:49 | <MikeSmith> | damn who fuglied up the desktop notifications in the Chromium trunk, and why |
| 07:29 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22422 is pretty ugly :/ |
| 07:30 | <annevk> | Maybe Hixie already handles that for images in HTML... But that wouldn't cover CSS so I guess not |
| 07:44 | <annevk> | Doesn't seem to be handled. I wonder if the HTTP gods are aware of this. |
| 08:34 | <annevk> | hallvors: so, 304 is a very distinct case from redirects |
| 08:35 | <annevk> | hallvors: I'm sure the HTTP gods had some interesting reason to mix it in with them, but when it comes down to it, the logic for it is different and it needs to be handled separately |
| 08:35 | <hallvors> | you're right |
| 08:36 | hallvors | is curious about Anne's religion |
| 08:36 | <hallvors> | I should rather investigate how much of that header stuff is implemented |
| 08:37 | hallvors | #stilsleepy |
| 08:40 | <annevk> | hallvors: I don't believe in the HTTP gods, but they do exist |
| 08:42 | <hallvors> | X-Anne-Faith: HTTP-Conditional |
| 08:42 | <hallvors> | Well, at least Chrome supports the 304 stuff in the spec as written |
| 08:42 | <hallvors> | according to your test |
| 08:43 | <hallvors> | I'm a bit surprised Opera didn't support it according to that test - because we did some work on behaving like a "caching proxy" for XHR a while back |
| 08:43 | <annevk> | That bug was still open when I still had an account :) |
| 08:43 | <hallvors> | (but there may also still be some magic somewhere that makes requests with query less caching) |
| 08:44 | <hallvors> | hm.. I thought some work was done on it, maybe not enough to actually ship a fix though |
| 08:44 | <annevk> | It's a bit unclear to me what the spec says is actionable enough. I feel like maybe we should turn that into some kind of flag too... |
| 08:44 | <hallvors> | I should look up the bug |
| 08:44 | <annevk> | E.g. if you set header 1 or 2, set the "pass 304 through flag". If that flag is set, don't change 304 into 200. |
| 08:47 | <annevk> | Or more likely, if it's unset, change 304 into 200 :) |
| 08:49 | <MikeSmith> | http://m.itworld.com/361807/foxconn-hire-3000-support-firefox-os-and-software-development |
| 08:50 | <annevk> | wow, they went from .5-1 Mozilla to 3 Mozillas pretty quickly |
| 08:50 | <karlcow> | hallvors: CORE-37327 |
| 08:50 | <karlcow> | maybe |
| 08:51 | <Ms2ger> | "It's looking for software engineers with skills in HTML5 operating systems" |
| 08:51 | <Ms2ger> | All 20 of them? |
| 08:55 | <miketaylr> | what if i have skills in 15 - 18 HTML5 OSes, do i get the job? |
| 09:00 | <annevk> | I think Ms2ger meant there's only 20 people with the relevant skills |
| 09:00 | <annevk> | Like that now decade old IBM job listing. Might as well list them by name |
| 09:02 | Ms2ger | thought of the same thing |
| 09:03 | <miketaylr> | boo, thanks for ruining my joke annevk |
| 09:03 | <karlcow> | :) |
| 09:06 | <hallvors> | karlcow: thanks - that's the fixed one, CORE-1033 is the still open one |
| 09:07 | <karlcow> | damned, I was not subscribed to this one. Not in my mail archive. :) |
| 09:51 | <SteveF> | hixie: appears the mutlipage and the one page of the whatwg spec are out of phase the multi-page is a day behind |
| 09:54 | <SteveF> | Hixie: appears the mutlipage and the one page of the whatwg spec are out of phase the multi-page is a day behind (once again with right nick) |
| 14:34 | <zewt> | hixie==hixie |
| 15:35 | <dglazkov> | good morning, Whatwg! |
| 16:00 | <TabAtkins> | annevk: What. The. Fuck. Jeezus, the webidl situation up in here is *fucked up* if all I want is freaking array of nodes with useful functions. |
| 16:01 | <TabAtkins> | annevk: On the other hand, going with NodeList means you don't get .filter or .map. |
| 16:01 | <TabAtkins> | This shouldn't be a choice we have to make. |
| 16:41 | <gsnedders> | FYI: am migrating remaining html5lib-python issues from Google Code. |
| 16:42 | <Ms2ger> | I read "to" |
| 17:36 | <gsnedders> | Zero issues remaining on GCode. |
| 18:50 | <abarth> | I tried to write a proposal that would let you connect to a remote window in a similar way to how you can connect to a shared worker: http://wiki.whatwg.org/wiki/RemoteDocumentMessaging |
| 18:50 | <abarth> | how badly did I screw it up? :) |
| 18:56 | <abarth> | i guess folks aren't around. I'll ask on the mailing list |
| 19:04 | <Hixie> | remote in what sense? |
| 19:04 | <abarth> | not in the same unit of related browsing contexts |
| 19:04 | <abarth> | e.g., you don't already have a JavaScript reference to the window object |
| 19:05 | <Hixie> | why not just use a shared worker? that's what they're for :-) |
| 19:05 | <abarth> | they consume resources |
| 19:05 | <abarth> | e.g., memory |
| 19:05 | <Hixie> | hmm |
| 19:06 | <abarth> | as far as I can tell, all the mechanisms exist in the platform |
| 19:06 | <Hixie> | so much as to be prohibitive? what are y'all putting in these workers? :-P |
| 19:07 | <abarth> | consider the use case in the wiki page |
| 19:07 | <Hixie> | i'm not sure window.name would be the best way to identify a target, but other than that this could work |
| 19:07 | <abarth> | should the word processing site always spin up a shared worker just in case? |
| 19:07 | <Hixie> | if they're cheap, yeah |
| 19:08 | <Hixie> | if they're not, i'd have gone more for a "broadcast message to same origin pages" approach, where you tell everyone "hey anyone out there?" and see if anyone responds |
| 19:08 | <abarth> | why not broadcast to some name within an origin? |
| 19:08 | <abarth> | if you've got a large origin with lots of different stuff |
| 19:09 | Hixie | sits down rather than typing over the desk |
| 19:09 | <abarth> | you don't want them have to bring all the pages out of swap |
| 19:09 | <abarth> | just to send them a message they don't care about |
| 19:09 | <Hixie> | yeah, that's fair enough |
| 19:09 | <Hixie> | window.name isn't unique |
| 19:10 | <Hixie> | in particular, what you really want in the case you mentioned on the wiki page is to broadcast to other instances of yourself |
| 19:10 | <abarth> | yeah |
| 19:10 | <Hixie> | so window.name would be awkward |
| 19:10 | <Hixie> | but you could register to receive messages on a particular topic, for instance |
| 19:10 | <abarth> | we should use a different name |
| 19:10 | <abarth> | window.subscribeTo("the-topic") |
| 19:11 | <Hixie> | another solution might be to make shared workers much cheaper by having a way to delay the actual shared worker creation until such time as multiple connections are attempted |
| 19:11 | <abarth> | window.broadcastMessage("hi there", "the-topic") ? |
| 19:11 | <Hixie> | but i'm not sure the shared worker being expensive is that big a deal. wouldn't an editor want a worker to be doing all the work in the background anyway? |
| 19:11 | <Hixie> | in which case, making it shared is a non-issue |
| 19:11 | <Hixie> | brb, oqne sec |
| 19:16 | <abarth> | I agree with you that if shared workers were free, web sites could build this mechanism themselves |
| 19:16 | <abarth> | but they're not free :) |
| 19:18 | <Hixie> | back |
| 19:18 | <Hixie> | yeah, but in the case of an editor, isn't it a sunk cost anyway? |
| 19:18 | <abarth> | I'm not sure I follow? |
| 19:18 | <Hixie> | wouldn't an editor want to put its networking and stuff in a worker? |
| 19:19 | <abarth> | this feature request is coming from the tech lead of an editor, and he says wouldn't need a shared worker anymore if we had this feature |
| 19:20 | <abarth> | currently, his shared worker is eating 70 MB of memory on my machine :) |
| 19:20 | <Hixie> | why wouldn't they use a worker, that's weird |
| 19:20 | <Hixie> | wait, wtf is he doing in his worker |
| 19:20 | <Hixie> | just to send messages takes 70 MB?! |
| 19:20 | <Hixie> | how about we fix that, rather than adding more features |
| 19:20 | <Hixie> | that's absurd |
| 19:20 | <abarth> | the problem is that shared workers are long-lived |
| 19:20 | <abarth> | so they accumulate resources |
| 19:21 | <Hixie> | that's... not how that works |
| 19:21 | <Hixie> | what are they accumulating? |
| 19:21 | <abarth> | e.g., the object graph grows if you're not careful to drop all references, and the heap fragments |
| 19:21 | <abarth> | dunno |
| 19:21 | <Hixie> | all he's doing is sending messages back and forth, how hard can it possibly be |
| 19:22 | <abarth> | by the way, I currently have zero documents open :) |
| 19:22 | <abarth> | one of the nice properties of the web is that resources are scoped to tabs |
| 19:23 | <abarth> | so you naturally clear them out as you browse around |
| 19:23 | <abarth> | shared workers are persistent, so they tend to accumulate cruft |
| 19:23 | <Hixie> | maybe i'm not understanding how this is going to work. when you open three of these tabs on the same document, is one of the tabs going to get promoted to master tab or something? |
| 19:23 | <abarth> | which means they require much higher skill levels use correctly |
| 19:23 | <Hixie> | and the others act as slaves? |
| 19:24 | <Hixie> | it just seems silly to me not to use a shared worker in this case. it's made for this precise thing. |
| 19:24 | <Hixie> | if it doesn't work for this, then we've failed and should just scrap shared workers. |
| 19:24 | <Ms2ger> | Sounds like it's time to land the Gecko implementation, then |
| 19:25 | <Hixie> | if there's only one document open, and the shared worker is only used for managing multiple documents, then we can make the shared worker take zero resources until another tab attempts to connect to it |
| 19:25 | <Hixie> | by having an API that says "but don't actually create it until there's another client" |
| 19:26 | <Hixie> | which is to say, i understand that if there's just one client, having a shared worker is more expensive than necessary. but with multiple clients, especially N > 2, it seems just silly to avoid them. |
| 19:26 | <abarth> | I guess I don't understand why you need something as complicated as a shared worker just to do cross-document messaging |
| 19:26 | <Hixie> | i don't understand why you think shared workers are complicated |
| 19:27 | <abarth> | I just want to send a message from one document to another. it seems unnecessary to make me write a third entity just to route the messages |
| 19:28 | <abarth> | should we make all cross-document messages flow through a shared worker? |
| 19:28 | <abarth> | why are cross-document messages in a single unit of related browsing contexts special and get to avoid the shared worker? |
| 19:28 | <abarth> | you agree it would be crazy to require a document to spin up a shared worker just to postMessage to one of its iframes, right? |
| 19:29 | <abarth> | or two iframes on the same page |
| 19:29 | <abarth> | so, why require a shared worker if the two iframes are in different windows? |
| 19:29 | <Hixie> | if it's 1:1, sure. but this use case isn't 1:1. it's n:n, with shared networking and shared document state, and with conflict resolution. |
| 19:29 | <Hixie> | that's not just 1:1 communication. |
| 19:30 | <abarth> | I don't understand how the "two iframes in the same window" case is different from the "two frames in different windows" case |
| 19:31 | <abarth> | my point is just that a shared worker is massive overkill for this use case |
| 19:31 | <Hixie> | i'm not saying it is, i'm saying this use case isn't that |
| 19:33 | <abarth> | let me connect this back to my original use case |
| 19:33 | <abarth> | there are two ways of opening word processing documents |
| 19:33 | <abarth> | you can go to the list of all your documents and open them |
| 19:33 | <abarth> | or you can make a new tab, and open it by pasting in the URL |
| 19:33 | hober | double click on it in Finder? :) |
| 19:34 | <abarth> | yes :) |
| 19:34 | <abarth> | in the first case, all the documents are in the same unit of related browsing contexts |
| 19:34 | <abarth> | and can communicate easily |
| 19:34 | <abarth> | in the second case, they can't because they don't have a script connection |
| 19:35 | <abarth> | so, just because they were opened by pasting in the URL, now they need to spin up a shared worker |
| 19:35 | <Hixie> | you're assuming that the user didn't open the list again to open the second doc |
| 19:35 | <Hixie> | (which i almost always do) |
| 19:35 | <abarth> | there are many ways they can end up without a script connection |
| 19:36 | <abarth> | but there are also cases where they share a script connection, depending on how you ended up opening the documents |
| 19:36 | <Hixie> | in the common case, there is no script connection. yes. |
| 19:36 | <Hixie> | what does it matter if there's a script connection or not? |
| 19:36 | <abarth> | why is a shared worker required in the second case but not in the first case? |
| 19:36 | <Hixie> | i'd use one if the first case too |
| 19:36 | <Hixie> | the shared worker makes this problem like a zillion times easier |
| 19:37 | <abarth> | in what way? |
| 19:37 | <abarth> | the shared worker seems like massively more complexity than I need here |
| 19:37 | <Hixie> | you don't have to implement a "slave" mode for the tab and "master" mode for the tab. |
| 19:37 | <abarth> | why do should I need to author a separate script just to route messages? |
| 19:37 | <Hixie> | you don't have to worry, e.g., about your "master" tab getting killed half-way through synchronising a complicated merge. |
| 19:37 | <abarth> | why do I have to elect a master? |
| 19:38 | <abarth> | i'm confused |
| 19:38 | <Hixie> | you want to try to do n-way edit merges using some sort of cooperative algorithm?? |
| 19:38 | <Hixie> | who should be in charge of sending the edits to the server, if not a master tab? |
| 19:39 | <Hixie> | this is just begging for a master-slave organisation. |
| 19:39 | <Hixie> | which is exactly what shared workers are for. |
| 19:40 | <abarth> | you're saying that one needs to be in charge of persisting the document to stable storage |
| 19:40 | <abarth> | normally, the server is in charge of that |
| 19:40 | <abarth> | if you're online, this is just a latency optimization to avoid round-tripping with the server |
| 19:41 | <Hixie> | one of them needs to be in charge of telling the server what the edits are |
| 19:41 | <abarth> | well, the edits originate in one window |
| 19:41 | <abarth> | the same problem occurs if the two documents are open on two different computers |
| 19:42 | <Hixie> | or the same computer in different browsers, sure. but in that case, they're not coordinating. |
| 19:42 | <abarth> | just in that case, you'll tolerate more latency to round-trip with the server |
| 19:42 | <abarth> | you could imagine being able to message between browsers, but that's a bit of an obscure case |
| 19:44 | <abarth> | thanks for the feedback. /me needs to get some lunch |
| 19:44 | <abarth> | I'll give it some more thought |
| 19:45 | <abarth> | https://code.google.com/p/chromium/issues/detail?id=161070 <--- If you're interested in this topic, you can CC yourself on this bug, which is the original feature request from the document editing folks |
| 19:47 | <Hixie> | separate from whether this use case should be solved that way, i don't a priori see anything wrong with a broadcast mechanism, fwiw. |
| 19:47 | <Hixie> | especially if we don't provide a zero-cost way to defer-start a shared worker. |
| 19:47 | <Hixie> | then i could see it as a way to coordinate when to start one, for instance. |
| 19:48 | <abarth> | this is related to the distributed locking proposal that fishd sent to the whatwg list a while ago |
| 19:48 | <abarth> | that's a sort of "one bit" coordination approach |
| 19:48 | <Hixie> | (not sure about using window.name, though. although maybe tha's better than having yet another registration mechanism.) |
| 19:49 | <abarth> | window.open("...", "the-channel") |
| 19:50 | <abarth> | has similar properties |
| 19:50 | <abarth> | in that you either create a new window or get back a way to communicate with an existing window of that name |
| 19:50 | <abarth> | but the security is screwed up because the names aren't scoped to an origin |
| 19:51 | <abarth> | it's the current "discovery" mechanism |
| 19:51 | <abarth> | but yeah, I'm not sure window.name is the right thing either |
| 19:51 | <abarth> | i'll be back in a bit after I get some lunch |
| 19:53 | <Hixie> | later. |
| 20:48 | <abarth> | I reworked the proposal to be a broadcast channel: http://wiki.whatwg.org/wiki/RemoteDocumentMessaging |
| 20:48 | <abarth> | there's still the question of whether a shared worker is a better fit for the use case, but I agree with you that the broadcast formulation is much cleaner |
| 21:04 | <TabAtkins> | abarth: Looks nice and simple! At least, it seems to basically just be a super-simple pre-provided Shared Worker that just forwards messages to all connected pages. |
| 21:05 | <TabAtkins> | In fact, maybe we can just do it like that? Define a browser-provided (about:?) link that starts up a forwarding Worker. |
| 21:05 | <abarth> | you'd still want to have channel names |
| 21:06 | <TabAtkins> | Yeah, deifnitely. |
| 21:06 | <TabAtkins> | Bake that into the urls as an extension point. |
| 21:06 | <TabAtkins> | var port = new SharedWorker("about:bouncer/foo").port; |
| 21:06 | <TabAtkins> | You need domain magic to make this work, I guess. |
| 21:07 | <abarth> | the other nice thing about a channel name is that you can use a nonce |
| 21:07 | <abarth> | and have something like a private channel |
| 21:07 | <TabAtkins> | I'm agreeing with you. ^_^ |
| 21:07 | <abarth> | sorry, I was just thinking outloud |
| 21:08 | <abarth> | I don't understand how this stuff interacts with transferable objects |
| 21:08 | <abarth> | like, does this support zero-copy sending of ArrayBuffers? |
| 21:08 | <TabAtkins> | Hm, neuterable objects wouldn't work, since it's multi-cast. |
| 21:08 | <TabAtkins> | Only things that could by copied. |
| 21:09 | <abarth> | so, can I send a MessagePort through the BroadcastChannel? |
| 21:09 | <abarth> | i guess only one listener would be able to receive it |
| 21:09 | <TabAtkins> | Those are copyable, no? |
| 21:09 | <TabAtkins> | Maybe not. |
| 21:09 | TabAtkins | doesn't know. |
| 21:58 | <TabAtkins> | abarth: You could have two types of bouncers - one that's multicast and accepts as many channels as you want, and one that's singlecast and only accepts two connections at a time. |
| 21:58 | <TabAtkins> | abarth: Dunno how to indicate that the connection limit has been hit - immediately send a message back saying that it's full? |
| 21:59 | <abarth> | that's sort of like the async lock proposal |
| 21:59 | <abarth> | except the limit is 1 |
| 21:59 | <abarth> | so, you're suggesting something more like a semaphore |
| 21:59 | <TabAtkins> | Yeah, but when you're trying to do a zero-copy transfer, that's exactly what you need. |
| 22:01 | <TabAtkins> | Two pages in an origin can use a multicast bouncer to coordinate with each other and agree on a singlecast channel name to use for transfer communication. |
| 22:01 | <TabAtkins> | about:bouncer and about:transferer? |
| 22:03 | <TabAtkins> | Reusing SharedWorker literally might not be the best idea - it may still be better to provide dedicated constructors - but I think explaining them in terms of browser-provided shared workers is pretty interesting. |
| 22:04 | <TabAtkins> | If we did use dedicated constructors, I like your BroadcastChannel name, and we can augment it with a TransferChannel name for the singlecast variant. |
| 22:20 | <abarth> | i'd have to think about how the transfer channel would handle error cases |
| 22:20 | <abarth> | you might want something that just hands off a message port to the parties |
| 22:20 | <abarth> | e.g., MessageChannel |
| 22:21 | <abarth> | you could imagine giving one of the message ports to the broadcast channel |
| 22:21 | <abarth> | and the first one to grab it wins |
| 22:24 | <TabAtkins> | Hmm, yeah, that's just as correct I guess. |
| 22:25 | <TabAtkins> | You'd need some way to explicitly open the port, or something like that. |
| 22:25 | <TabAtkins> | First to attach an onMessage handler? |
| 22:25 | <abarth> | there's a start() function |
| 22:26 | <abarth> | so, you could claim it by doing that |
| 22:26 | <TabAtkins> | Ah, indeed there is. |
| 22:26 | <TabAtkins> | I'd missed that. |
| 22:27 | <TabAtkins> | So that's just a matter of adding a constructor to MessagePort, which is nice and elegant. |
| 22:27 | <TabAtkins> | Well, kinda. |
| 22:28 | <TabAtkins> | You need to get a pair of them. |
| 22:28 | <abarth> | that's what MessageChannel does for you |
| 22:28 | <TabAtkins> | So yeah, MessageChannel. |
| 22:28 | <abarth> | it has port1 and port2 |
| 22:28 | <TabAtkins> | Oh, durp, I should really read this whole Workers chapter again. |
| 22:28 | <abarth> | the missing piece is a way to hand one of the ports to the remote document |
| 22:28 | <abarth> | without a script connection |
| 22:28 | <abarth> | my first draft went after that problem directly |
| 22:29 | <abarth> | but letting you trigger a "connect" event on the remote document |
| 22:29 | <abarth> | with the message port |
| 22:29 | <TabAtkins> | Yeah, and the BroadcastChannel works well. I like it's elegance - the way it can be described as a browser-defined "bouncer" SharedWorker. |
| 22:29 | <abarth> | but that felt a bit like electing a leader |
| 22:29 | <TabAtkins> | Yeah. |
| 22:29 | <abarth> | since there's a distinguished instance that gets the connect event |
| 22:29 | <abarth> | and if you're going to elect a leader, you probably should be using a shared worker |
| 22:30 | <abarth> | so the leader can outlive all the followers |
| 22:30 | <abarth> | BroadcastChannel is more symmetric |
| 22:30 | <TabAtkins> | Yup. |
| 22:40 | <TabAtkins> | abarth: Problem with just transferring the port is that it gets neutered as it is transferred. You can't have the broadcast channel send it to multiple other senders. |
| 22:40 | <abarth> | Maybe BroadcastChannel could allow transferrable if there's only one listener? |
| 22:41 | <abarth> | so, you could agree with someone what channel name to use |
| 22:41 | <abarth> | and then hop onto that channel |
| 22:42 | <abarth> | e.g., one channel is used for signaling and the other is used for data |
| 22:42 | <TabAtkins> | That does mean that it's possible to be DOSed by something else on your origin, but that's probably a sufficiently okay problem - you can already have lots of bad things happen from your own origin. |
| 22:42 | <abarth> | if they want to DOS you, they can just make a sync XHR :) |
| 22:42 | <abarth> | they don't even have to be in your origin |
| 22:43 | <TabAtkins> | I meant that something else on your origin, which knows your signaling channel, can listen in and connect to any ports you attempt to use for data. |
| 22:43 | <TabAtkins> | But they're already within your origin, so you're screwed. |
| 22:44 | <TabAtkins> | And I don't see how that's possible to solve without a direct connection anyway. You *must* use a spoofable token to identify the channel, precisely so that the other side can spoof it. |
| 22:58 | <abarth> | TabAtkins: you could make up a nonce on the server |
| 22:58 | <abarth> | and send it to the two pages |
| 22:58 | <abarth> | and they could use it as the channel name |
| 22:59 | <TabAtkins> | Sure, there are ways to avoid it if you bring in a trusted third party. |
| 22:59 | <TabAtkins> | Anyway, I dont' think it's a real concern. |
| 22:59 | <TabAtkins> | If an attacker is inside your origin, you're already screwed. |
| 22:59 | <abarth> | I wonder if NamedChannel would be a better name |
| 22:59 | <TabAtkins> | Hm, maybe. |
| 22:59 | <abarth> | you might even subclass MessageChannel |
| 23:00 | <abarth> | and the ports could null themselves out as they were grabbed |
| 23:01 | <abarth> | i guess that doesn't work as well for the broadcast case |
| 23:01 | <abarth> | and there's a race condition |
| 23:01 | <TabAtkins> | Yeah. |
| 23:02 | <TabAtkins> | You'd have to agree on which port each should take. |