| 01:09 | <Hixie> | jgraham: btw, i'll probably comment out the vertical text stuff soon since CSS doesn't yet define how to render it |
| 04:05 | <micheil> | Hixie: websockets: ready for public comsumption by the end of the year? |
| 04:05 | <micheil> | (or hopefully ready) |
| 04:33 | <aho> | mmm... websockets... nom nom :v |
| 04:46 | <Hixie> | micheil: i'm not aware of any known issues, but the hybi wg seems to have a lot of members who basically want to start over |
| 04:47 | <micheil> | Hixie: please not. |
| 04:47 | <micheil> | Hixie: just wanted to give you a heads up on: http://plancast.com/a/40wi/record_episode_030_-_websockets_freenode_thechangelog_saturday_july_31_2010_500pm |
| 04:48 | <Hixie> | i have no idea what i'm looking at :-) |
| 04:49 | <micheil> | okay, basically a popular opensource oriented podcast is doing an episode on websockets, and their current usage |
| 04:49 | <Hixie> | if you don't want the hybi wg to change everything, i recommend saying so on the list -- right now there seems to be a lot of people who have said they think the protocol shouldn't be designed for amateurs, and if that isn't a requirement, the protocol would be radically different |
| 04:49 | <micheil> | it's being recorded next weekend |
| 04:49 | <Hixie> | ah, nice |
| 04:49 | <micheil> | quite frankly, I don't think it's a protocol designed for ametuers |
| 04:49 | <micheil> | *amatuers |
| 04:50 | <Hixie> | well it might not succeed, but it is designed for them :-) |
| 04:50 | <Hixie> | if i wasn't designing with amateurs in mind, i'd just do it always TLS, and support things like multiplexing built-in |
| 04:52 | <micheil> | well, really, do we need TLS on always? |
| 04:52 | <micheil> | I mean, saying that could imply that HTTP was designed with amateurs in mind |
| 04:56 | <micheil> | Hixie: isn't TLS fairly expensive to achieve? |
| 04:56 | <micheil> | ie. meaning that websockets with TLS wouldn't be a disposable transport |
| 05:42 | <Hixie> | TLS isn't really that expensive relative to other costs involved in a long-lived connection at this point, as I understand it |
| 05:42 | <Hixie> | the main cost of TLS, as I understand it, is connection setup and the block-based encryption which increases latency of short bits, but the latter could presumably be worked around easily enough |
| 05:43 | <Hixie> | (this is not my area of expertise, though) |
| 05:43 | <Hixie> | i've no idea what HTTP's design criteria were |
| 05:43 | <Hixie> | but at this point HTTP certainly isn't trivially implementable if you want a complete conforming implementation, either on the client or on the server |
| 07:08 | <othermaciej> | Hixie: out of curiosity, are there any existing protocols that are simple enough to be implemented by amateurs? |
| 07:08 | <othermaciej> | (either client or sever sides thereof) |
| 07:08 | <Hixie> | not a network protocol, but CGI |
| 07:09 | <othermaciej> | that's definitely an example where stock servers implemented a network protocol and exposed a simpler semi-standardized interface for hand-rolled software to plug in |
| 07:09 | <micheil> | I think we should really drop the idea that websockets are easy. |
| 07:09 | <micheil> | it's up to the implementors of the protocol to make it easy to work with. |
| 07:09 | <micheil> | but the protocol itself doesn't need to be easy for developers |
| 07:09 | <micheil> | (if that makes sense) |
| 07:10 | <Hixie> | i think that assumes that the developers and the implementors of the protocol are going to be distinct |
| 07:10 | <micheil> | well, I'm making that distinction |
| 07:10 | <othermaciej> | I think citing CGI as an example would tend to argue that Websockets should also follow the CGI model to solve the "amateur" use case |
| 07:10 | <othermaciej> | I wonder if there is any case of a network protocol that is widely implemented directly from scratch |
| 07:10 | <micheil> | if you make a web app, you're probably not also writing the http server to power it. |
| 07:11 | <Hixie> | only because http is so hard to implement |
| 07:11 | <micheil> | you're probably using nginx, apache or something like that. |
| 07:11 | <micheil> | so, the people that write the things to work with the protocol are the implementors, the developers are the ones that use implementations to make awesome stuff |
| 07:11 | <Hixie> | my point is that the only reason we don't see people implementing protocols so often is that they're hard to implement |
| 07:11 | <othermaciej> | the IRC protocol has been implemented many times I guess, does it tend to get implemented from scratch by people whose main goal is something besides just "implement IRC"? |
| 07:12 | <othermaciej> | IRC bots tend to talk IRC directly, but I have no idea if people use libraries to implement them |
| 07:12 | <micheil> | I mean, when people first started catching on to websockets and node.js, there were about 10 different implementations, all of which didn't actually implement the protocol to specification |
| 07:14 | <othermaciej> | If there is no existing example of a protocol people often implement from scratch just to make a piece of toy software, then it may be that there is in fact no such thing, and then it would be pointless to try to serve that use case |
| 07:14 | <Hixie> | that's tautological |
| 07:15 | <othermaciej> | if there are examples of such protocols, then they could be useful for convincning people that it's a worthwhile property of a protocol |
| 07:15 | <Hixie> | that line of argumentation regresses to nobody ever trying |
| 07:16 | <othermaciej> | has anyone ever tried before? |
| 07:16 | <othermaciej> | if so, have they succeeded or failed? |
| 07:16 | <Hixie> | not to my knowledge |
| 07:16 | <othermaciej> | what can we learn from their attempts? |
| 07:17 | <Hixie> | i'm not aware of any attempt to design a protocol that is purposefully kept simple enough that it is possible for amateurs to implement it in a few days other than CGI |
| 07:17 | <Hixie> | (on the server side) |
| 07:17 | <Hixie> | (obviously on the client side we've designed tons of APIs that way, that's what the web is made of) |
| 07:17 | <othermaciej> | CGI is not a network protocol though |
| 07:17 | <othermaciej> | it's a design intended to hide the complexity of what was, at the time, a very simple protocol |
| 07:19 | <othermaciej> | sure, but APIs aren't really comparable to network protocold |
| 07:19 | <Hixie> | why not? |
| 07:21 | <othermaciej> | because you don't have to build your intraction with them out of low-level primitives like select() and read() |
| 07:21 | <othermaciej> | the DOM is a significantly higher-level abstraction than Unix system calls |
| 07:22 | <Hixie> | *shrug* |
| 07:22 | <Hixie> | i don't buy that that matters |
| 07:23 | <othermaciej> | I think the reason people don't build network protocols from scratch is not because every existing protocol is too complicated but rather because Unix system calls are too low-level an abstraction to be convenient |
| 07:23 | <othermaciej> | as supporting evidence, I would cite the fact that amateurs rarely write *any* software that directly interacts with Unix system calls |
| 07:23 | <Hixie> | come now, it's not that hard |
| 07:24 | <othermaciej> | I would say you have zero evidence for the assertion that it's "not that hard" |
| 07:24 | <Hixie> | not sure what would count as evidence |
| 07:25 | <othermaciej> | examples of types of code that amateurs often write from scratch using read/write/select or a similarly low-level interface |
| 07:25 | <Hixie> | i'm not a professional programmer and i've had minimal trouble implementing network code in multiple languages |
| 07:26 | <othermaciej> | I think the "amateur programmers" you are concerned about are at least 3 standard deviations below you on the IQ scale |
| 07:26 | <othermaciej> | so I would not accept "not hard for Ian Hickson" as evidence |
| 07:27 | <othermaciej> | unless your goal is just to make something simple to implement for people 3 or 4 standard deviations above the mean IQ who happen not to be paid primarily to program |
| 07:28 | <Hixie> | i don't know of any situation before websockets where what you describe as suitable evidence would have come up |
| 07:28 | <othermaciej> | well there's lots of things you *could* do with raw Unix syscalls |
| 07:28 | <Hixie> | like what? |
| 07:29 | <othermaciej> | it just happens that in every case where that is a possibility, the vast majority of people use higher-level libraries |
| 07:29 | <Hixie> | even with websockets i expect most people to use libraries, that doesn't mean we should not cater for people who don't use libraries |
| 07:29 | <othermaciej> | three examples: implementing the "load" or "save" feature of a random toy application; reading config files; launching applications |
| 07:29 | <Hixie> | most web APIs are abstracted out by libraries too |
| 07:30 | <Hixie> | if it makes you more willing to accept it as a requirement, we can also phrase it as "keep the protocol as simple as possible to limit the number of bugs that professional programmers make" |
| 07:31 | <micheil> | Hixie: as long as it's implementable by reading the spec and as long as I don't need a ITC doctorate + phd to understand it, I'm cool. |
| 07:31 | <Hixie> | just look at the mess "professional programmers" have made of simple APIs like postMessage() or simple protocols like HTTP |
| 07:31 | <othermaciej> | let's say we accepted the premise that no matter what the protocol design is, .01% of people will implement from scratch instead of using a library - would it then be useful to cater to the "direct implementation" use case? |
| 07:31 | <othermaciej> | I totally agree that the protocol should be as simple as possible to limit bugs |
| 07:31 | <othermaciej> | it's already kind of scary complicated on the client side |
| 07:31 | <othermaciej> | I only find that acceptable because significant complexity is needed just to make it secure |
| 07:32 | <Hixie> | my goal is just to have the protocol be trivial, i don't really care if we phrase it as "cater to amateurs" or "limit bugs that libraries will have" or whatnot, it's all the same result in practice |
| 07:32 | <Hixie> | i just find it easier to think about what concretely is simple or not when i consider a hypothetical amateur programmer than when i just think of keeping it "simple" |
| 07:33 | <othermaciej> | no matter what your goal is, you should not use a fallacious argument as the public justification for it |
| 07:33 | <othermaciej> | I do think there are material differences in the two standards though |
| 07:33 | <Hixie> | (a third way of phrasing it is that the protocol should be as minimal a layer above TCP as possible, since we're just trying to do TCP for the Web) |
| 07:34 | <othermaciej> | for the hypothetical "professional programmer who might make mistakes", a requirement to use a TLS library would be no greater a burden than a requirement to use TCP |
| 07:34 | <Hixie> | that's clearly not the case |
| 07:34 | <Hixie> | the number of buggy TLS configurations on the web is clear evidence of how wrong that is |
| 07:35 | <othermaciej> | is it greater than the number of buggy non-TLS configurations on the Web? |
| 07:35 | <othermaciej> | (not sure how to compare, since I do not know what you mean by "buggy configration") |
| 07:36 | <Hixie> | i have no idea what your question means |
| 07:36 | <othermaciej> | anyway, I bet if you proposed a standard of "as simple as possible, to limit the mistakes made even by professional/expert implementors", in place of "simple enough for amateurs", I bet nearly everyone would agree |
| 07:36 | <Hixie> | i mean things like self-signed certs, wrong certs, etc |
| 07:36 | <othermaciej> | evn if you think the two standards are equivalent in practice |
| 07:36 | <othermaciej> | I see |
| 07:37 | <othermaciej> | surely you can't count those kinds of things as programming errors |
| 07:37 | <Hixie> | making TLS libraries do the right thing is orders of magnitude more complex than making select() do the right thing |
| 07:37 | <othermaciej> | the people who programmed Apache have nothing to do with what kind of cert you put on your server |
| 07:37 | <Hixie> | you're the editor of the requirements doc, i'll let you deal with justifying it :-) |
| 07:37 | <othermaciej> | I'm trying to quit! |
| 07:38 | <othermaciej> | but fine, I will propose that wording and see who objects |
| 07:38 | <Hixie> | the protocol i'm designing is a trivially-implementable TCP for web browsers |
| 07:38 | <Hixie> | if that's what hybi wants, it's what they'll get |
| 07:38 | <Hixie> | if it's not, i'll do it elsewhere |
| 07:38 | <Hixie> | we're only doing it in the hybi wg because the ietf told me that they wanted to have the trivially-implementable TCP for web browsers spec i was working on done at the IETF |
| 07:39 | <Hixie> | if they change their mind, I don't really mind |
| 07:39 | <Hixie> | that's up to them |
| 07:39 | <Hixie> | so i don't really feel the need to justify this particular aspect of the design; for me, it's a given |
| 07:39 | <othermaciej> | shouldn't your goals be driven by use cases? |
| 07:40 | <Hixie> | who said they weren't? |
| 07:40 | <Hixie> | the use case collection for this stuff happened years ago |
| 07:40 | <Hixie> | around 2005 |
| 07:40 | <othermaciej> | you seem to be saying that you have some standard of "trivially implementable" that you are not willing to revise based on arguments or data, and which is not clearly driven by a realistic use case |
| 07:41 | <Hixie> | http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity |
| 07:42 | <colapop> | For a site like Wikipedia, would it be "semantic" to put the nav links for article/discussion/edit/history/etc. within the <article> element? |
| 07:42 | <Hixie> | colapop: yes |
| 07:42 | <othermaciej> | Sure, but that's no reason not to http://www.w3.org/TR/html-design-principles/#solve-real-problems |
| 07:42 | <Hixie> | we are |
| 07:42 | <othermaciej> | you said that if you didn't have this "amateur programmer" standard, you would make at least two changes which could solve real problems |
| 07:42 | <othermaciej> | (require TLS, include multiplexing) |
| 07:43 | <micheil> | seriously, why do we want TLS? |
| 07:43 | <micheil> | I see pretty much 0 benefit. |
| 07:43 | <micheil> | do most people browser the web always using https? |
| 07:43 | <estellevw> | is it <event-source> or <eventsource> |
| 07:43 | <othermaciej> | micheil: two basic reasons |
| 07:44 | <micheil> | othermaciej: please, do explain. |
| 07:44 | <othermaciej> | micheil: (1) it's much easier to get through a proxy with SSL over port 443 rather than non-SSL over port 80, with a bidirectional protocol |
| 07:44 | <Hixie> | othermaciej: i consider not having the keep-it-simple standard as equivalent to not having to worry about use cases, in which case i'd be designing a protocol for aethetics and theory, not real problems |
| 07:44 | <othermaciej> | (Google gathered some data and found only about a 60% success rate over port 80) |
| 07:44 | <micheil> | actually, there will be a larger dataset coming out soon on websocket support. |
| 07:44 | <Hixie> | othermaciej: i hadn't really considered that there might be people who want to "solve real problems" without also keeping the protocol as simple as possible |
| 07:45 | <micheil> | I can't say much more then that at the moment though |
| 07:45 | <Hixie> | estellevw: neither |
| 07:45 | <othermaciej> | Hixie: I think the standard should be "as simple as possible while addressing the most important (80% use case) problems" |
| 07:45 | <Hixie> | othermaciej: sure, that's what websockets is for |
| 07:46 | <Hixie> | estellevw: (the element is gone, now it's just an API) |
| 07:46 | <micheil> | I would actually do a test on a highly proxied & filtered network, but alias, the network actually blocks all my own domains. |
| 07:46 | <othermaciej> | micheil: (2) it's much easier to design a protocol that you can be confident won't cause security problems for existing Web servers if it's built on top of TLS |
| 07:46 | <estellevw> | thanks hixie. |
| 07:46 | <micheil> | (this network would be the NSW Department of Education network, which I have been told is one of the most highly filtered networks around) |
| 07:47 | <othermaciej> | Hixie: that standard is clearly *not* equivalent to "trivially implementable from scratch" or "simple enough for an amateur to implement" |
| 07:47 | <micheil> | othermaciej: (2) not really. |
| 07:47 | <Hixie> | othermaciej: i don't see any concrete difference |
| 07:47 | <othermaciej> | Hixie: that standard would say, if there is a useful piece of functionality that puts the feature out of reach of amateur implementors, you add it anyway |
| 07:47 | <Hixie> | othermaciej: no |
| 07:47 | <othermaciej> | I mean, imagine the version of <video> that is simple enough for amateurs to implement |
| 07:47 | <micheil> | If I'm going to have to implement TLS, I'm going to find it damn hard; and if you get it wrong, then what's the good? |
| 07:47 | <othermaciej> | it would be pretty useless |
| 07:48 | <Hixie> | othermaciej: ok, i do think that websocket should be implementable by a broader range of people than something aimed exclusively at web browser vendors |
| 07:48 | <micheil> | othermaciej: besides, if you really want security: use the ssl / wss upgrade. |
| 07:48 | <micheil> | connect using SSL. |
| 07:49 | <othermaciej> | micheil: you're going to have to trust me that (2) is true, but I don't have the time right now to explain security against cross-protocol attacks in detail |
| 07:49 | <Hixie> | othermaciej: for example, i think the ConnectionPeer protocol, whatever that ends up being, can easily be orders of magnitude more complex to implement than WebSockets, since it only needs to be implemented a few times, mainly by browser vendors, maybe a couple of times for stand-alone servers |
| 07:49 | <othermaciej> | Hixie: pro browser vendors are definitely not immune to mistakes :-) |
| 07:50 | <micheil> | othermaciej: seriously, how often do you see someone cross-protocol attacking one of your servers. Not to say it doesn't happen. but I just think it's fairly rare. |
| 07:50 | <othermaciej> | but I agree that the client side of Web protocols is likely to be implemented fewer times |
| 07:50 | <Hixie> | othermaciej: but WebSockets is likely to be implemented many orders of magnitude more times than that; for one, i'd expect every programming language to end up with a library to implement it |
| 07:50 | <Hixie> | othermaciej: they're not immune to mistakes but they get FAR more testing |
| 07:50 | <Hixie> | than your average custom server |
| 07:50 | <othermaciej> | I think "Server side of a Web network protocol" falls somewhere between "client-side implementation of something Web-facing" and "use of a Web API" in maximum acceptable complexity |
| 07:50 | <Hixie> | or scripting library |
| 07:51 | <micheil> | actually, from what I've heard, a fair few people in the php community have already found draft76 too hard to implement, so they've turned to using things like node.js + node-websocket-server |
| 07:51 | <othermaciej> | based just on number of people likely to do it |
| 07:51 | <Hixie> | micheil: yeah, we've had several people come here in #whatwg asking for help because it's too complex already |
| 07:51 | <Hixie> | micheil: that's one reason i am so reluctant to go any further and add more complexity |
| 07:52 | <micheil> | I think my own websocket library, while not up to 100% spec, I think it's at about 80-90% |
| 07:52 | <Hixie> | micheil: i'd love to find way to make it simpler, but i can't see how to do so while still hitting the 80% othermaciej mentions |
| 07:52 | <othermaciej> | I think for this particular protocol, the security requirements are in major tension with ease of implementation |
| 07:52 | <Hixie> | clearly |
| 07:53 | <othermaciej> | it's unfortunate that client-side security concerns have to be in tension with ease of implementation for servers |
| 07:53 | <othermaciej> | I think multiplexing could be added in a way that it has zero impact on servers that don't want it |
| 07:53 | <othermaciej> | but it would add a *lot* of complexity for clients |
| 07:53 | <othermaciej> | and significant security risk |
| 07:53 | <othermaciej> | I don't think it would have some of the benefits people imagine either |
| 07:54 | <Hixie> | multiplexing is pointless to add at the protocol level |
| 07:54 | <othermaciej> | to really reduce the rate of keepalive pings, you need to consolidate keepalives for connections to multiple servers |
| 07:54 | <Hixie> | it's easy to add at the application layer for people who want it |
| 07:54 | <Hixie> | and TCP doesn't have it |
| 07:54 | <Hixie> | do you know why we can't use TCP keepalives, btw? |
| 07:55 | <othermaciej> | does TCP have keepalives? |
| 07:55 | <othermaciej> | I don't think it does |
| 07:55 | <Hixie> | sure, just send an empty packet |
| 07:55 | <micheil> | seriously, I only just understand what multiplexing is, but I can't see how I'd benefit from using it at a web developer level |
| 07:55 | <othermaciej> | well, it doesn't have built-in passive keepalives |
| 07:55 | <othermaciej> | clearly you could use an empty TCP packet as a WebSocket keepalive |
| 07:56 | <othermaciej> | or at least, I can't think of a reason why not |
| 07:56 | <othermaciej> | however, the problem I would worry about is, what if you have WebSocket connections open to 10 different servers |
| 07:56 | <othermaciej> | that's more likely than 10 connections to 1 server |
| 07:56 | <othermaciej> | it sucks that you have to send a bunch of packets |
| 07:57 | <othermaciej> | seems like it could be avoidable in principle if you are talking to all 10 servers through a single proxy |
| 07:57 | <micheil> | othermaciej: so far I've never noticed a client sending empty packets just to keep the socket alive. |
| 07:57 | <othermaciej> | (my understanding is that keepalive is needed primarily to keep intermediaries from severing the connection) |
| 07:57 | <micheil> | but I am some what abstracted from the network level api |
| 07:57 | <Hixie> | i don't really see much point in keepalives personally |
| 07:58 | <Hixie> | but they're easily done at the application layer also |
| 07:58 | <micheil> | Hixie: agreed. |
| 07:58 | <Hixie> | so if people have subprotocols that don't send much data, they can do it easily |
| 07:58 | <othermaciej> | is there such a thing as a use of WebSocket where you will provably never need keepalives? |
| 07:58 | <micheil> | it just makes application logic slightly more complicated. |
| 07:58 | <Hixie> | frankly though if you're sending so little data that you need keepalives, i'd strongly recommend considering whether HTTP might not solve your needs better |
| 07:59 | <Hixie> | othermaciej: sure, any game where you send state regularly, for instance |
| 07:59 | <Hixie> | othermaciej: or anything where the server sends regular updates |
| 07:59 | <micheil> | or for a chat server |
| 07:59 | <micheil> | or other realtime interaction |
| 08:00 | <micheil> | there's been talk already in the serverside javascript movement of an end-to-end javascript static, with websockets being the communication medium |
| 08:00 | <othermaciej> | I don't understand enough about the problem that keepalives try to prevent |
| 08:00 | <Hixie> | keepalives as i understand it basically solve the problem of NATs thinking your connection is old and thus forgetting about it |
| 08:01 | <othermaciej> | I think if you are waiting for the server to notify you, and both the client and the server have nothing to send for a while, you definitely need keepalives, and using HTTP you will still need them |
| 08:01 | <Hixie> | so they stop routing packets properly |
| 08:01 | <Hixie> | if you're just waiting for server notifications, EventSource is likely more up your alley, and the server can send regular "no updates yet" messages if necessary |
| 08:02 | <micheil> | EventSource does look interesting, especially for push-only events |
| 08:02 | <othermaciej> | if the client could possibly gain enough knowledge of network topology to avoid the need of keepalives, that too would be a possible reason to have them built-in |
| 08:02 | <micheil> | there's actually a library that's combining things like bayuex, websockets, eventsource, etc into one communication medium, which is kind of interesting |
| 08:03 | <micheil> | othermaciej: so far I've not needed to even touch keepalives. |
| 08:03 | <othermaciej> | eventsource is neat because it's trivial to deploy |
| 08:03 | <othermaciej> | you can just use your favorite web stack and there's no need to worry about weird network configurations |
| 08:09 | <micheil> | which should be what websockets should be. |
| 08:09 | <micheil> | all you should need in order to use websockets is a server with some application level logic + a client that connects. |
| 08:19 | <othermaciej> | unfortunately, it's more complicated than that :-( |
| 08:28 | <micheil> | othermaciej: it shouldn't have to be. |
| 08:34 | <ksemeks> | is there a book or something about html5/js ? |
| 08:37 | <micheil> | ksemeks: no, but there is a really good course being done by John Allsopp over at sitepoint |
| 08:37 | <micheil> | http://courses.sitepoint.com/html5-live |
| 08:37 | <micheil> | (well, I don't know of a book) |
| 08:38 | <micheil> | as for javascript, take your pick of books. |
| 08:38 | <micheil> | javascript's a massive thing, and a powerful language, if you use it right. |
| 08:39 | <ksemeks> | i picked 'Javascript: The definitive guide', of OReaily |
| 08:40 | <ksemeks> | is there a better one, ? .. |
| 08:45 | <micheil> | that's a pretty good book, JavaScript: The good parts is also good. |
| 08:45 | <micheil> | the best way to learn javascript is to read javascript |
| 08:46 | <micheil> | (by that, I don't mean trying to read the source code to jquery first up) |
| 08:46 | <micheil> | I mean, try looking at things like the language syntax |
| 08:47 | <ksemeks> | im familiar with the syntax |
| 08:47 | <micheil> | in which case, pick something to do with it. |
| 08:48 | <micheil> | (i think my first javascript thing was making a "webos" because those things were somewhat trendy at the time.) |
| 08:48 | <ksemeks> | ok :) |
| 08:51 | <micheil> | ksemeks: although, start simple. |
| 08:51 | <micheil> | and don't just learn jQuery or another js library, because they may abstract you too far from the language |
| 08:53 | <cyberix> | I wrote a simple example about sending binary data with XHR2. http://cs.helsinki.fi/u/twruottu/binpost.js |
| 08:55 | <cyberix> | I am not sure it works. I just wrote it so I'd have something to show. |
| 08:55 | <cyberix> | Do I need to construct the Blob myself, or should I use some library function for that? |
| 08:56 | <cyberix> | in the example 2/3 of the code is about defining/constructing a blob |
| 08:56 | <cyberix> | having a constructor provided by browser would really help |
| 08:57 | <micheil> | and what exactly is a Blob? |
| 08:57 | <micheil> | because "foo" isn't binary data. |
| 08:59 | <cyberix> | http://dev.w3.org/2006/webapi/FileAPI/#blob |
| 09:00 | <cyberix> | by "foo" I mean 0x66 0x6F 0x6F |
| 09:00 | <cyberix> | that is what it becomes when you turn it into data:,foo |
| 09:01 | <micheil> | okay |
| 09:01 | <micheil> | well, iirc, there aren't any current binary implementations native to javascript |
| 09:13 | <cyberix> | that is not a problem |
| 09:13 | <cyberix> | constructing the blob by hand is |
| 10:14 | <jgraham> | micheil: I don't quite understand your position on websockets. Do you believe it should be easy to implement servers ( the "amateur programmer" requirement). Do you believe it currently succeeds in this goals? |
| 10:15 | <jgraham> | s/goals/goal/ |
| 10:19 | <jgraham> | (those questions are orthogonal i.e. you might believe it is simple currently but need not be) |
| 13:34 | <micheil> | jgraham: I believe it's simple enough; I think adding ssl / tls as a requirement would over complicate it |
| 13:35 | <micheil> | I don't see it as a protocol implementable by "the amateur programmer", but rather something that while it does require some background knowledge to implement, it's not super technical. If you read the spec, then all the information is there – it's well documented. |
| 13:39 | <micheil> | adding any form of encryption would be unnecessary for what I think the majority of uses for websockets would be, look at the ways that realtime communication in the browser is currently being used |
| 13:40 | <micheil> | there's a few cases, where, ssl security may be good (such as in analytics applications, or specialised chat applications) but I think for every day use, eg, for the standard chat network, or collaborative tool, I don't think SSL is of much importance |
| 13:41 | <micheil> | and if you have a situation which would be benefited from having encryption, eg, when dealing with business data, then you can add it on, like you do with ssl encryption to HTTP |
| 13:42 | <micheil> | jgraham: in essences, being simple / easy for amateur programmers to implement shouldn't be a requirement, as any protocol can be implemented by an amateur. |
| 13:43 | <micheil> | It's just a matter of how correctly that protocol is implemented. |
| 13:44 | <micheil> | I believe that you shouldn't need a PHD in security or something like that in order to implement it though. Such that the protocol shouldn't have any unneeded complexitty (if this complexity can be dramatically simplified through adequate documentation, I'm fine with that too. ) |
| 13:45 | <micheil> | does that make sense? |
| 13:55 | <jgraham> | micheil: Ok |
| 13:56 | <jgraham> | micheil: So you are in favour of simplicity as a design goal, but not necessarily with the expression of it as an "amateur programmer" requirement? |
| 13:56 | <micheil> | yes |
| 13:56 | <micheil> | simplicity makes things less likely to break. |
| 13:56 | <micheil> | be it by design or implementation. |
| 13:57 | <micheil> | because the last thing that you want is a specification and protocol that no-one wants to use because it's too complicated to get started with |
| 13:58 | <micheil> | at the same time, I don't expect someone who is entirely knew to programming / the concepts of html to be able to use a websocket server, which is fair enough. |
| 13:58 | <jgraham> | Agreed. I tend to believe that the other requirement that is hidden in the "amateur programmer" description is that one should not need a significant amount of network-protocol-writing experience to make a server implementation |
| 13:59 | <micheil> | I mean, I'm different to most, in that I actually have some of a background with network protocols, and have tried to implement a few and spent some time at uni learning about them briefly. |
| 14:00 | <micheil> | despite that, I'm no one that's good with high level mathematics, security, etc. It takes a hell of a lot to be able to understand a lot of network security, above the basic measures |
| 14:01 | <jgraham> | It seems to be a theme that having punchy names for design requirements works well for small groups mostly in agreement but works poorly when the size of the group expands |
| 14:01 | <jgraham> | The same thing happened with the HTMLWG |
| 14:01 | <jgraham> | People got hung up over the names for principles rather than their motivations |
| 14:02 | <jgraham> | (of course it is possible to disagree with something when you fully understand the motivation) |
| 14:03 | <micheil> | currently, the websocket protocol, to me seems secure, the only times it's not, are when you can crash a server when sending the wrong packets (which I've done, and it was a server level implementation detail, not a problem with websockets)] |
| 14:03 | <jgraham> | (but there seems to often be a phse of attacking strawmen derived from the name) |
| 14:03 | <micheil> | "phse of attacking strawmen"? |
| 14:05 | <Philip`> | s/phse/phase/ |
| 14:05 | <micheil> | yeah, I got that; but what do you mean by it? |
| 14:07 | <jgraham> | micheil: For example on the hybi list people claiming that the amateur programmer requirement implied something like "the protocol has to be implementable by people with IQ 90" and using that to attack the requirement |
| 14:08 | <micheil> | I'd have no idea what my IQ is, but I do know that I'm best to leave security to those that specialise in it, just as I often leave design to those that specialise in it. |
| 14:09 | <micheil> | specifications aren't something you just write for fun because you like theoretical implementations and theoretical problems. You write them because there's actually a problem that needs to be solved and that you want to see it solved for a better future of development |
| 14:09 | <jgraham> | micheil: I have no idea what my IQ is either nor do I want to know, but IQ 85ish is supposed to be 1sigma below the mean so ~15% of people have IQ < 85 |
| 14:10 | <micheil> | if you want to come up with 1000 reasons why something is secure, then why do we bother implementing anything, as everything is eventually insecure. |
| 14:12 | <micheil> | for the rest of stuff, we just want a way to more easily build richer web interactions. |
| 14:12 | <micheil> | *rest of us |
| 14:12 | micheil | is really way too tired tonight. |
| 14:12 | <jgraham> | micheil: Yes, security is difficult. It is hard to know if the Websocket security is good enough currently. I can easilly believe that the TLS proposal has better security properties but it comes at a high cost to implementations |
| 14:13 | <micheil> | I think the overhead of the implementation would be enough to mean that you'd dramatically reduce usage. |
| 14:14 | <micheil> | and like I said: most people browse the web use http (I have actually done fulltime browsing with https, as it circumvented a proxy filter, but that's another story) |
| 14:14 | <micheil> | so, really, if you were to redesign http now, would you make it by default require SSL? |
| 14:15 | <micheil> | rather, TLS |
| 14:15 | <jgraham> | I think a good yardstick for simplicity would be "can I implement websockets in popular scipting langauges using only the stdlib" |
| 14:15 | <micheil> | yes |
| 14:16 | <jgraham> | (not a sufficient condition but a necessary one) |
| 14:16 | <micheil> | (as it is, I actually already depend on openssl for the md5 summing, because the bindings provided in node.js are such) |
| 14:19 | <micheil> | although, if by default you require tls, would that not also mean you'd need a certificate of authority? |
| 14:21 | <jgraham> | Apparently not |
| 14:22 | <micheil> | okay, news to me. I know you can do self-signed certificates, but I do know that a lot of browsers often throw a warning at that. |
| 14:25 | <jgraham> | I am under the impression that the TLS proposal can use TLS in a no-certificate mode |
| 14:25 | <jgraham> | But I am the definition of non-expert here |
| 14:25 | <micheil> | which doesn't really add security then, does it? |
| 14:26 | <micheil> | / if it does, then why on earth do I have to pay hundreds of dollars for a certificate from someone like tharwte |
| 14:27 | <micheil> | *thawte |
| 14:28 | <jgraham> | I believe it is addressing a different security concern |
| 14:28 | <micheil> | I'm totally confused now. |
| 14:30 | <jgraham> | I mentioned the non-expert thing, right? |
| 14:30 | <jgraham> | :) |
| 14:30 | <micheil> | yeah, full disclaimer and all. |
| 14:30 | <jgraham> | I would suggest you ask someone else to explain it because they are less likely to be horribly confused than me |
| 14:30 | <jgraham> | Notably abarth, since it is his proposal |
| 14:31 | <micheil> | to put blankly, given enough knowledge and experience, every protocol is hackable using the simple telnet client or XMLHttpRequest |
| 14:31 | <micheil> | and if not a simple telnet client, then with openssl running as a telnet client |
| 14:32 | <jgraham> | telneting into a WebSockets server is not really hacking it though |
| 14:32 | <jgraham> | In the important sense here |
| 14:32 | <micheil> | well, it is accessing it outside of what it was designed to be used with |
| 14:33 | <jgraham> | Possibly using XMLHttpRequest to access a websockets server would be a problem, but that should be impossible |
| 14:33 | <jgraham> | The main concern is the reverse; using a websockets client to access an SMTP server |
| 14:33 | <micheil> | on draft75 it was more plausible, hence the reason for the sec-* stuff |
| 14:33 | <micheil> | abnd key3 |
| 14:33 | <jgraham> | and send spam |
| 14:34 | <micheil> | okay, ten points if you can do that. |
| 14:34 | <micheil> | telnet a SMTP server, send it http headers and see what it does. |
| 14:34 | <micheil> | you'll probably just get your connection closed. |
| 14:34 | <jgraham> | micheil: Apparently it will ignore them |
| 14:34 | <jgraham> | I have a reference for this, wait a moment |
| 14:34 | <micheil> | k |
| 14:35 | <jgraham> | http://www.remote.org/jochen/sec/hfpa/hfpa.pdf |
| 14:36 | <jgraham> | For that reason if you try to POST to port 25 in a browser you will find it is blocked |
| 14:36 | <micheil> | then again, my ISP blocks me from accessing :25 |
| 14:37 | <micheil> | and really, if that is the case, then it should be the other protocols that are getting upgrades / patches to fix them against this |
| 14:38 | <jgraham> | That clearly isn't a good enough solution |
| 14:38 | <micheil> | would it be an idea to implement this security at client-side level? |
| 14:39 | <jgraham> | You can't just release a new protocol which opens up security problems and then say "well it's someone else's problem" |
| 14:39 | <micheil> | okay, fair point. |
| 14:40 | <micheil> | but I don't see it as something that requires a server-side change. |
| 14:42 | <micheil> | the websocket client is to expect back a valid http header structure, with a status code of 101, if it doesn't receive that, then it should close the connection |
| 14:42 | <micheil> | (iirc, the spec actually says something very similar to that.) |
| 14:44 | <jgraham> | That was more or less -75. And it was deem insufficiently secure |
| 14:44 | <jgraham> | *deemed |
| 14:45 | <micheil> | right |
| 17:48 | <hsivonen> | Why is Web Socket still being discussed as if it were up for discussion? surely the window of opportunity for changing it is closing fast as multiple implementations are about to ship? |
| 18:11 | <gsnedders> | Because creating a spec that people agree on is more important than one browsers will implement? |
| 18:32 | <AryehGregor> | Do screen readers treat <ins> and <u> (for instance) any differently? |
| 18:33 | <jgraham> | hsivonen: Yeah, I tend to agree |
| 18:33 | <AryehGregor> | Or <b> and <strong>, etc.? |
| 18:33 | AryehGregor | needs to get a screen reader to test this kind of thing with. |
| 18:35 | <jgraham> | hsivonen: I think unless the current spec is shown to have substantial security problems the cost of change at this stage is likely to be prohibitive |
| 18:37 | <jgraham> | And I would prefer we had discussions on that basis rather than the basis of what would be better given a clean slate of implementations |
| 18:43 | <Hixie> | jgraham, hsivonen: if you think that, you shoudl tell the hybi list |
| 18:44 | <jgraham> | Hixie: Fair point |
| 18:48 | <hsivonen> | I'm not going to start participating on hybi |
| 18:49 | <Hixie> | btw have you noticed how traffic has dropped to zero again on that list? |
| 18:49 | <Hixie> | after i stopped posting? |
| 18:49 | <Hixie> | there is a direct correlation between the volume of traffic and my posting to the list |
| 18:50 | <Hixie> | i wonder if there is causation, or if i'm just affected by the same external factors as everyone else |
| 18:51 | <hsivonen> | I don't read hybi, so I don't have observational data |
| 18:53 | <Philip`> | Hixie: You should generate a random posting schedule, so that the days you post are not correlated to any outside influence |
| 18:53 | <Hixie> | i'm considering it |
| 18:55 | <hsivonen> | are there any plans to support Web Socket multiplexing over SPDY? |
| 19:00 | <Hixie> | i hope not |
| 19:00 | <Hixie> | what would the point be? |
| 19:45 | <hsivonen> | Hixie: conserving kernel-level resources and using already-established TCP windows |
| 19:45 | <hsivonen> | Hixie: perhaps not a good optimization |
| 20:14 | <Hixie> | hsivonen: you can do multiplexing already using shared workers |
| 20:15 | <hsivonen> | Hixie: doesn't that require the JS layer to do the multiplexing? |
| 20:15 | <Hixie> | yes |
| 20:16 | <hsivonen> | if multiplexing is desirable, wouldn't it make sense to make the bowser manage it? |
| 20:16 | <hsivonen> | *browser |
| 20:16 | <Hixie> | the author has to manage it on the server-side anyway |
| 20:17 | <Hixie> | it's not clear that forcing a particular multiplexing scheme on the protocol is desireable |
| 20:17 | <Hixie> | TCP doesn't do multiplexing |
| 20:17 | <gsnedders> | But TCP is lower level anyway |
| 20:17 | <Hixie> | websockets is supposed to be TCP for browsers |
| 20:17 | gsnedders | doesn't get the relvence there |
| 20:17 | <Hixie> | if it wasn't for security concerns, we'd just be using TCP |
| 20:17 | <gsnedders> | I thought websockets was built on TCP. Obviously I misunderstood. |
| 20:18 | <gsnedders> | (There again, when I last looked at the spec was, uh, years ago) |
| 20:18 | <Hixie> | websockets is the minimal amount on top of TCP to make TCP work for browsers |
| 21:43 | <annevk> | what a backlog... |
| 21:44 | <annevk> | you'd think less would happen in a week in July on the interwebs |
| 21:45 | <annevk> | email not completely dealt with count went from its normal 700 to high 1800 |
| 21:48 | <Hixie> | heh |
| 21:53 | <annevk> | yay for abarth |
| 22:01 | <estellevw> | In what cases, if any, would the :optional UI pseudo class match an element. :required matches form elements with the required attribute, which is boolean, so true if present |
| 22:01 | <jgraham> | annevk: Yeah, he should get a medal or something |
| 22:01 | <estellevw> | is it all form elements that don't have the attribute set? |
| 22:02 | <hsivonen> | annevk, jgraham: for general awesomeness or something in particular? |
| 22:02 | annevk | just noticed the URL-spec thread |
| 22:02 | <hsivonen> | ah |
| 22:04 | <estellevw> | answered my own question - any form element that does not have the attribute of required |
| 22:05 | <hsivonen> | hmm. no new objection on the versioning poll |
| 22:08 | <jgraham> | hsivonen: We have a few more days though, right |
| 22:08 | <jgraham> | ? |
| 22:09 | <jgraham> | I will reply to that, but it takes more effort than the ascii one |
| 22:09 | <hsivonen> | jgraham: yeah, it'll be open for a few days, still |
| 22:16 | <annevk> | from Hixie on hybi "I apologise in advance if this causes a spike in traffic to the list." |
| 22:17 | <annevk> | and a spike it was, geez :) |
| 22:17 | <annevk> | 71 emails! |
| 22:18 | <Hixie> | only 71? |
| 22:24 | <annevk> | well, in that particular thread |
| 22:38 | <Hixie> | annevk: oh in that comment i meant all the threads, not just that one |
| 22:38 | <Hixie> | but i didn't check the numbers |
| 22:39 | <Hixie> | 71 just sounds a bit low for what it felt like :-) |
| 22:47 | <annevk> | sounds like you get even more email than me if you are underwhelmed by 71 ;p |
| 22:59 | <Hixie> | annevk: i have 1735 e-mails in my list of e-mails to reply to :-) |
| 23:55 | <jamesr> | i think we should add an explicit iteration cap to http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#adoptionAgency |
| 23:56 | <jamesr> | running the algorithm without a count takes time quadratic in the length of the input |