/irc-logs / freenode / #whatwg / 2008-04-25 / end

Options:

# Session Start: Fri Apr 25 00:00:00 2008
# Session Ident: #whatwg
# [00:01] * Hixie comments on the slashdot post to say he agrees with microsoft
# [00:02] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [00:06] <Philip`> Hixie: You're replying far too late, nobody's even going to see your message :-p
# [00:12] <Hixie> excellent
# [00:19] <Lachy> Hixie, was that the slashdot post about the GPL?
# [00:19] <Hixie> html5
# [00:20] <Hixie> http://slashdot.org/comments.pl?sid=533346&cid=23184908 is pretty much exactly right
# [00:20] <Lachy> oh, I didn't even see that post before :-)
# [00:23] <Lachy> any particular sections you think should be taken on by other editors, if they were available?
# [00:25] <Philip`> I'd expect that depends a lot on who the editor is - some will find some sections really boring, and they wouldn't do any work on it for years, but might find other sections interesting and be happier to work on them
# [00:26] <Philip`> so you can't define a single ordered list of things that should be extracted from the spec
# [00:26] <Hixie> lachy: first, we need editors for the sections that even i have abandoned: http://wiki.whatwg.org/wiki/Companion_specifications
# [00:27] <Philip`> Hixie: Those all look like really boring things :-)
# [00:27] <Hixie> why do you think i abandoned them!
# [00:28] <Lachy> once I can get selectors api mostly out of the way, into CR, I may be able to look at taking one of those on
# [00:28] <hsivonen> what would be an example of a server-side DOM3 Core feature?
# [00:28] <Lachy> although, I've got the html5 guide and xbl primer to work on still
# [00:28] <Philip`> Hixie: It doesn't seem very effective to try recruiting editors by pointing them at a list of really boring things and saying they should work on those first
# [00:29] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
# [00:29] <Hixie> Philip`: are there non-boring things?
# [00:29] <Hixie> spec writing is hard work and pretty boring
# [00:29] <Dashiva> Surely 3d canvas at least should be (relatively) exciting
# [00:29] <Hixie> brb
# [00:29] <Lachy> I like writing specs more than some of my other responsibilities at work
# [00:29] <Philip`> Hixie: Probably not, but maybe there are some things that are just quite boring and not really boring :-)
# [00:30] <Hixie> Philip`: css3 animation would be fun
# [00:30] <Dashiva> Don't worry Lachy, next year someone else will be the coffee boy
# [00:30] <Hixie> hough difficult
# [00:30] * Quits: qwert666 (n=qwert666@acat177.neoplus.adsl.tpnet.pl) ("Leaving")
# [00:31] <Philip`> Dashiva: I'd guess 3d canvas is mostly trying to work out what all the OpenGL state is and what functions depend on it and how to be sure browsers don't crash or have security bugs when people trying calling functions in a crazy order
# [00:31] <Lachy> Dashiva, I wish we had a decent coffee boy! All we have are machines that make terrible hot chocolates, and canteen staff that keep filling the Nesquik container with poor quality substitues.
# [00:31] <Philip`> which still isn't great fun
# [00:32] <Philip`> (and then it'll still be a source of all sorts of bugs, just because video drivers are buggy)
# [00:33] <Lachy> isn't there supposed to be a joint task force with the webapi wg to work on the canvas stuff?
# [00:35] <Lachy> ah, that's in the proposed web api charter. I guess it will start after that charter takes effect
# [00:35] * Quits: KevinMarks (n=KevinMar@nat/google/x-6622f7a03d04b179) ("The computer fell asleep")
# [00:35] <Philip`> The fun way to write specs would be to write lots of crazy demos and games and things, and say that any implementation which can run those demos is following the spec well enough
# [00:36] <Philip`> Lachy: http://wiki.whatwg.org/wiki/Companion_specifications ?
# [00:36] <Philip`> Uh
# [00:36] <Philip`> Forgot to copy
# [00:36] <Philip`> Lachy: http://www.w3.org/2007/12/WebApps-Charter-2007 ?
# [00:36] <Lachy> yep
# [00:37] <Dashiva> Lachy: I figured chaals had set you up with a proper espresso machine. My mistake :)
# [00:40] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
# [00:47] * Joins: JDuke64 (n=JDuke32@212.174.90.98)
# [00:50] * Quits: JDuke64 (n=JDuke32@212.174.90.98) (Client Quit)
# [01:00] * Joins: weinig__ (n=weinig@nat/apple/x-5097fe835ead394a)
# [01:01] * Quits: tndH (i=Rob@adsl-87-102-32-128.karoo.KCOM.COM) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
# [01:03] <Hixie> http://developers.slashdot.org/comments.pl?sid=533346&cid=23190802
# [01:03] * Quits: eseidel (n=eseidel@nat/google/x-21fdffbdb28721ff)
# [01:03] <Hixie> not sure how to reply to that in a way that doesn't insult the people working on that spec...
# [01:03] <Philip`> Has that ever stopped you before?
# [01:07] <Lachy> just explain that xhtml modularisation is a completely different concept from splitting up the HTML5 spec
# [01:10] <Hixie> i'll let y'all handle that one :-)
# [01:10] <Dashiva> It seems to me that MoinMoin can't generate <th> in tables
# [01:10] <Dashiva> How's that for accessibility...
# [01:12] <Philip`> <td colspan="3" style="text-align: center"><p class="line891"><strong>Heading</strong></td>
# [01:12] <Philip`> (via http://moinmoin.wikiwikiweb.de/HelpOnTables )
# [01:12] <Dashiva> Ayup
# [01:14] <Philip`> The wiki-code for tables looks fairly ugly - does anybody have a nice way of marking up tables?
# [01:16] * Joins: othermaciej (n=mjs@17.203.15.181)
# [01:17] * Quits: weinig (n=weinig@17.203.15.172) (Read error: 110 (Connection timed out))
# [01:17] * Philip` kind of likes the LaTeX syntax, since you normally only need a single line of setup code and then every row is like "cell1 & cell2 & cell3 \\" which is about as minimal as possible
# [01:17] <Dashiva> Mediawiki's way is bad because it clashes with template syntax, but just markup-wise it covers most of it
# [01:17] <Philip`> (http://en.wikibooks.org/wiki/LaTeX/Tables etc)
# [01:17] * Quits: jgraham_ (n=jgraham@81-86-217-60.dsl.pipex.com) (Read error: 110 (Connection timed out))
# [01:18] * Quits: billmason (n=billmaso@ip127.unival.com) (".")
# [01:18] <Dashiva> (You can't do the fancy stuff like col/colgroup/thead etc, but they allow plain html for the complex stuff)
# [01:18] * Quits: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk) ("Ex-Chat")
# [01:19] <Philip`> (Does that mean you can write a simple table with the wiki syntax, then add a few more complex features, but once you get to a certain point and want another feature you have to rewrite the entire thing into HTML?)
# [01:20] <Dashiva> No, you can just copypaste the output of the old code :)
# [01:20] <Lachy> Hixie, you might be able to answer this more better than I can. http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx#8422881
# [01:20] <Philip`> Dashiva: What if you want to remove that final feature and convert it back to the wiki syntax? :-)
# [01:20] <Dashiva> Run a regexp on it :)
# [01:20] <Lachy> s/more better/better/
# [01:21] <Dashiva> You could even write a wikicode serializer and link it to html5lib!
# [01:23] <Hixie> Lachy: commented
# [01:28] * weinig__ is now known as weinig
# [01:29] * Philip` wonders if it's possible/sensible for a script to override document.write and intercept all the written strings
# [01:30] <Philip`> (I'd like to let pages get proper HTML5 parsing by adding a line <!doctype html><script src=html5parser.js></script> to the top, but that seems like it'd be a bit messier if the page tries doing fancy scripting stuff itself)
# [01:32] <Lachy> Hixie, there's a few more exceptions you forgot to mention, like always appending link and meta elements to the head, even if it's not open.
# [01:32] <Lachy> though, I suppose that doesn't insepct the DOM to do that, it just maintains a separate head pointer
# [01:37] * Joins: othermaciej_ (n=mjs@17.255.107.219)
# [01:45] * Quits: othermaciej (n=mjs@17.203.15.181) (Nick collision from services.)
# [01:45] * othermaciej_ is now known as othermaciej
# [01:48] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [01:50] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [01:55] * Joins: othermaciej_ (n=mjs@17.203.15.181)
# [01:56] * Joins: mcarter (n=mcarter@pool-72-87-174-227.plspca.dsl-w.verizon.net)
# [01:56] <mcarter> hello
# [01:56] * Joins: Lachy_ (n=Lachlan@ti200710a340-3723.bb.online.no)
# [01:57] * Quits: othermaciej (n=mjs@17.255.107.219) (Nick collision from services.)
# [01:57] <mcarter> othermaciej, I'm curious what your proposal is for an http based protocol for TCPConnection?
# [01:57] * othermaciej_ is now known as othermaciej
# [01:57] * Joins: Facedown (n=HELLO@c-68-48-58-38.hsd1.md.comcast.net)
# [01:57] <mcarter> othermaciej, Hixie mentioned that the protocol was your main objection
# [01:57] <othermaciej> mcarter: I don't have a full proposal for how to satisfy the TCPConnection use cases
# [01:58] <mcarter> othermaciej, Ok, I'm at least interested in the reasons for it
# [01:58] <othermaciej> my two problems with it are: (1) it uses port/host addressing instead of URI addressing, which is a poor fit for the Web model
# [01:58] <mcarter> othermaciej, I'm putting together a document about the pros and cons of http for TCPConnection
# [01:58] <othermaciej> (2) it's bad to send non-http over the assigned ports for http and https
# [01:59] <othermaciej> (3) I am worried that connection to arbitrary ports could lead to security issues, although Hixie tried hard to avoid them
# [01:59] <othermaciej> (basically the only security mechanism though is assuming that no other protocol will happen to emulate the TCPConnection handshake, which seems pretty weak)
# [02:00] <othermaciej> (given that other protocols have been found to have multiple interpretation vulnerabilities)
# [02:00] <othermaciej> I guess that is three problems
# [02:00] <mcarter> ok
# [02:00] <mcarter> i had a couple of other concerns
# [02:00] <mcarter> With SSL there is no way to do virtual hosting -- you have to route on ip address... HTTP/1.1 upgrade with TLS solves this problem
# [02:01] <othermaciej> mcarter: I think a custom http method that begins a two-way session might be a promising solution, but I think that would require a proof of concept that it is viable on client and server side
# [02:01] <mcarter> Http provides the Host header to avoid dns rebinding attacks
# [02:01] <mcarter> othermaciej, it seems to me the way to do it is send an OPTIONS with an Upgrade: tcp/1.0 header as the client->server tcp handshake
# [02:01] <othermaciej> mcarter: those are also good points
# [02:02] <mcarter> also, HTTP based connections include query parameters and cookies, allowing for normal auth mechanisms
# [02:03] <mcarter> othermaciej, i'll add your three points to my document
# [02:04] <mcarter> the big hurdle is keeping it simple enough for Hixie's requirements, particularly that it be possible to implement in just a few lines of perl
# [02:04] <Philip`> use Net::HTML5::Connection;
# [02:04] <Philip`> run_server();
# [02:05] <Philip`> Should it be a few lines of Perl that a normal Perl programmer would write, or a few lines that a Perl golfer could write?
# [02:05] * Quits: aroben (n=aroben@unaffiliated/aroben)
# [02:05] <mcarter> Philip`, he wants it to be 3 lines with no support libraries
# [02:07] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [02:07] <Hixie> i dunno about 3
# [02:08] <Hixie> i think i said a few dozen
# [02:08] <Hixie> but the point is it has to be a fully compliant implementation
# [02:08] <Philip`> Is there any problem that can't be solved in a few dozen lines of Perl?
# [02:09] * Joins: Lachy__ (n=Lachlan@ti200710a340-1179.bb.online.no)
# [02:09] <takkaria> the travelling salesman problem?
# [02:10] * Quits: Lachy (n=Lachlan@85.196.122.246) (Nick collision from services.)
# [02:10] * Quits: Lachy_ (n=Lachlan@ti200710a340-3723.bb.online.no) (Nick collision from services.)
# [02:10] * Lachy__ is now known as Lachy
# [02:10] <Philip`> takkaria: That's a trivial problem to solve - just enumerate all possibilities and pick the best
# [02:11] <takkaria> quickly, then. :)
# [02:11] <Philip`> It's trivial to do it quickly, at least for certain input sizes :-)
# [02:13] <takkaria> OK, I'll stop defending my quick and ill-thought-out reponse now
# [02:13] <takkaria> anyone else want a go? :)
# [02:20] * Joins: jwalden (n=waldo@RANDOM-SIX-THIRTY-TWO.MIT.EDU)
# [02:20] <Philip`> perl -lpe'@==sort@p=map$_.shift@=,@@for@@=/,|\pL/g;$_=@p[$`]'
# [02:20] * Quits: weinig (n=weinig@nat/apple/x-5097fe835ead394a) (Remote closed the connection)
# [02:20] <Philip`> Apparently that does the Burrows-Wheeler transform, but I don't quite see how :-/
# [02:21] * Joins: weinig (n=weinig@17.203.15.172)
# [02:22] <jwalden> Hixie: in 6.4.1, you can't check the origin of the target document while postMessage is running -- what happens if the target window is navigated to another location before the event is dispatched?
# [02:26] <jwalden> as far as I can tell, the only thing you can/must do at postMessage time is determine the origin of the caller; everything else must happen immediately before the event is dispatched
# [02:26] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
# [02:27] <mcarter> Hixie, oh, i think we could get it done in just a few lines of code even if it was http-based
# [02:29] <mcarter> Hixie, i don't think saying "it should be implementable in 3-10 lines of perl" is unreasonable whatsoever
# [02:34] <othermaciej> mcarter: my vague idea was to repurpose the CONNECT method, since that is likely to already work through proxies
# [02:35] <othermaciej> mcarter: but developing the proper server-side support would be tricky
# [02:35] <othermaciej> so I feel like it is not worth suggesting without proof-of-concept client and server impls
# [02:35] <othermaciej> I think the two-way persistent connection problem may just have to get solved after HTML5
# [02:37] <mcarter> othermaciej, well, I'm working on a proof of concept so feel free to suggest to me any ideas you have
# [02:41] * Joins: shepazu (n=schepers@123.127.99.15)
# [02:46] * Joins: mcarter_ (n=mcarter@pool-72-87-174-7.plspca.dsl-w.verizon.net)
# [02:46] * Quits: tommorris (n=tommorri@i-83-67-98-32.freedom2surf.net)
# [02:47] <mcarter_> othermaciej, i lost connectivity there, but i had try to say that you should give me any ideas/suggestions you have for bi-directional communication protocols because I'm making a proof of concept client and server
# [02:49] * Quits: mcarter (n=mcarter@pool-72-87-174-227.plspca.dsl-w.verizon.net) (Nick collision from services.)
# [02:49] * mcarter_ is now known as mcarter
# [02:50] * Joins: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk)
# [03:15] * Joins: sverrej (n=sverrej@89.10.27.86)
# [03:19] <othermaciej> mcarter: ok, so my idea was to overload CONNECT, have an apache module that lets a CGI script or similar handle this, and have it establish a two-way TCP connection
# [03:19] <othermaciej> mcarter: using "upgrade" also seems like an interesting idea though may be less proxy-compatible
# [03:19] <Philip`> Apache module sounds scary
# [03:20] <othermaciej> I have no idea how hard or easy it is to write an Apache module but I assume it is easier than an IIS plugin
# [03:20] <Philip`> Apache modules don't work too well in lighttpd either :-(
# [03:21] <othermaciej> I'm not sure there is a viable solution that will work with every existing httpd
# [03:21] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
# [03:21] <othermaciej> (Hixie's approach was basically to run services that don't hook into httpd at all on totally separate ports)
# [03:23] <Philip`> I'm not sure what problem this is trying to solve, so I suppose I should find that out first
# [03:24] <othermaciej> the problem is enabling full duplex messaging between a client and a server over a single established TCP connection (to avoid overhead of constantly creating and destroying connections)
# [03:24] <Philip`> Server-sent events + XHR with HTTP pipelining?
# [03:24] <othermaciej> the closest thing to it over http is http pipelining combined with a multipart (or otherwise incremental) http response
# [03:25] <Philip`> (or just keepalive)
# [03:25] <Hixie> my main use case was on a machine that didn't even have a web server
# [03:25] <Hixie> but that's another story
# [03:25] <Hixie> jwalden: woops, good point
# [03:25] <Hixie> jwalden: fix on the way
# [03:26] <othermaciej> XHR with pipelining might be viable, but there's no solution on the server side (afaik) to bind a pipeline to a single process which handles all requests on it
# [03:26] <othermaciej> so if you have a front-end server that farms out requests to individual process/threads to serve them, you have not really solved the use case
# [03:27] <othermaciej> also http pipelining is currently not viable on the client side
# [03:27] <Philip`> I'm pretty sure Opera did XHR pipelining when I last tested it
# [03:27] <othermaciej> Opera tries to use super clever heuristics to figure out when it can avoid any of the servers or proxies that create problems
# [03:27] <Philip`> Ah
# [03:28] <Philip`> That sounds interoperable
# [03:28] <othermaciej> but I don't think anyone else has enough faith in their ability to come up with sufficiently clever heuristics
# [03:29] <Philip`> Aren't the servers and proxies likely to cause just as many problems for a brand new persistent-two-way-connection-over-HTTP thing than for pipelining?
# [03:29] <othermaciej> an http pipeline does also impose quite a bit of protocol-level overhead if your messages are small, though maybe that doesn't matter in practice
# [03:29] <mcarter> othermaciej, i don't think the Uprade header has anything to do with proxies. We'll still need to put send a CONNECT to the proxy no matter what protocol we choose
# [03:29] * Quits: heycam (n=cam@124-168-100-30.dyn.iinet.net.au) ("bye")
# [03:29] <othermaciej> Philip`: the problem with pipelining is that some servers (and proxies) will scramble multiple responses when you give them pipelined requests
# [03:29] <mcarter> also, I don't like http pipe-lining at all -- the only way to restart a stream is to close the actual tcp connection, or send http responses back to all the "acks" that have built up
# [03:30] <othermaciej> Philip`: however, CONNECT does give you a way to tunnel a connection over the proxy at least for SSL that seems to work
# [03:30] <mcarter> othermaciej, with the apache stuff, i don't think the topic is how someone should implement tcp connection, rather what protocol should be used
# [03:31] <mcarter> othermaciej, later on, apache or anyone else can go ahead and implement whatever api/interaction with their current stuff that they want
# [03:32] <mcarter> Philip`, server sent events + XHR, without pipelining provides a pretty workable duplex stream, but its really hard to implement
# [03:32] <Philip`> Is this feature meant to work for people with very restricted networks that allow nothing except HTTP (maybe HTTPS) connections and only to their proxy server?
# [03:33] <Philip`> mcarter: Ah, I suppose the pipelining doesn't actually matter except for latency
# [03:33] <Philip`> (but I was looking at this in the context of a multiplayer FPS, where latency is pretty important)
# [03:34] <mcarter> Philip`, yeah, for upstream latency you'd have to do somethign with multipart to make it reasonable
# [03:35] * Philip` wonders which direction is upstream
# [03:35] <mcarter> good point. From a client/server point of view, upstream counts as towards the server, at least thats how I use the term
# [03:35] <Philip`> Okay
# [03:35] <mcarter> Philip`, a full duplex mechanism for the browser should work over restricted networks where traffic must pass through firewalls and/or http forward proxies
# [03:36] <mcarter> Philip`, so we'll definitely need to send a CONNECT to the forward proxy either way
# [03:36] <Philip`> Are there proxies that block everything except GET and POST?
# [03:36] * Philip` doesn't know how much effort people put into making their networks useless
# [03:37] <mcarter> possibly, but they still support CONNECT for https
# [03:37] <mcarter> CONNECT to a proxy basically means, "now ignore any more bytes that go up or down this connection"
# [03:38] <Philip`> That sounds like a good feature to lock down when all your annoying users are trying to Skype through your network
# [03:38] <othermaciej> mcarter: one requirement that Hixie (rightly) states is that this new approach must be reasonably easy to deploy on the server side
# [03:38] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [03:39] <othermaciej> mcarter: I haven't proposed a protocol in part because I feel like I would need to prove it is viable with code
# [03:39] <othermaciej> just making a protocol proposal isn't very helpful in itself
# [03:39] <mcarter> othermaciej, this is precisely what i'm working on
# [03:39] <mcarter> othermaciej, i'm making an implementation of the TCPConnection api in the browser that speaks to a special server that understands sse and xhrs as being upstream and downstream
# [03:40] <mcarter> othermaciej, then that server opens a raw socket connection to the destination, and speaks the appropriate protocol
# [03:40] <mcarter> othermaciej, so any browser code can use the javascript api, and the server code can just be a socket server that implements whatever the protocol is supposed to be
# [03:40] <mcarter> othermaciej, so I'm interested in feedback as I put together a few example server implementations of that protocol
# [03:41] <othermaciej> mcarter: I don't see the point of that
# [03:41] <othermaciej> mcarter: it doesn't do anything to show viability of directly integrating support for the protocol into an existing server infrastructure
# [03:41] <mcarter> one of the demos could easily be an apache module, if thats what you think it would take to prove anything
# [03:42] <mcarter> personally, i'm more with hixie that it should be a few lines of perl
# [03:42] <othermaciej> well, it's certainly not the only way
# [03:42] <othermaciej> a few lines of perl almost certainly can't be a specific URI on the same host and port your document came from
# [03:42] <othermaciej> anything where you have to pick a custom host and port can't work purely within the same-origin security model
# [03:43] * Quits: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
# [03:43] <mcarter> othermaciej, i believe the plan is to allow at least cross-sub-domain and probably fully cross-domain tcp connections
# [03:43] <Hixie> yeah
# [03:43] <othermaciej> yes, that is what TCPConnection allows, and one of the things I dislike about it
# [03:43] <Hixie> oh?
# [03:44] <jwalden> hm, this making the argument thing isn't so non-trivial if you actually decide to be principled and determine what the argument *should* be if it's provided and not "*"
# [03:44] <othermaciej> the only security measure is assuming no other current or future network service can emulate the handshake
# [03:44] <mcarter> othermaciej, it doesn't really make sense to just come up with some special protocol to speak to http servers. As I see it, TCPConnection to *other* services/daemons will enable a whole class of applications
# [03:44] <jwalden> s/thing/non-optional thing/
# [03:44] <othermaciej> (or can be tricked into emulating the handhsake)
# [03:44] <othermaciej> but TCPConnection can't talk to an arbitrary existing service
# [03:44] <othermaciej> it has to talk to a custom service written for TCPConnection
# [03:45] <Hixie> jwalden: you only need to include it in the reply, really, right? in which case just pass event.origin
# [03:45] <mcarter> othermaciej, of course. but custom socket services are trivial to write, and give you the power of full duplex communication without banging your head against a wall or using flash
# [03:45] <jwalden> Hixie: I have so many convolutions in most of these tests that it isn't always that simple
# [03:45] <Hixie> jwalden: heh
# [03:45] <jwalden> Hixie: further, providing the literal value is good defense anyway
# [03:45] <othermaciej> it's like combining the worst parts of something http-based (can't talk to existing services) and something socket-based (no URI addressing, no same-origin security, no ability to leverage common http-based infrastrucutre)
# [03:46] <othermaciej> that is the core of what is wrong with TCPConnection, in my mind
# [03:46] <Hixie> jwalden: oh i agree
# [03:46] <Hixie> jwalden: i expect there are two major use-cases
# [03:46] <othermaciej> I want the full duplex functionality on a URI on my server
# [03:46] <jwalden> so except in one or two cases where I'm using a single file generically, I have to determine what the exact value is
# [03:46] <othermaciej> not a separate port on some other host
# [03:46] <Hixie> jwalden: talking to a specific page on a specific host (in which case, it's known), and talking to anyone (in which case, it doesn't matter)
# [03:46] <othermaciej> with no addressing of resources below host granularity
# [03:46] <mcarter> othermaciej, I agree that the tcpconnection should be able to talk to your standard server. an integration with apache for instance
# [03:46] <Hixie> jwalden: though i agree that often test cases end up being complicated for this kind of thing!
# [03:47] <mcarter> othermaciej, but why not also let it talk to a custom service?
# [03:47] <othermaciej> imagine I am logged into www.mychatservice.com
# [03:47] <othermaciej> and the site wants to send my messages back and forth over a full duplex connection
# [03:47] <othermaciej> if it's not over http to the same server, it can't rely on my cookies as the auth credential
# [03:47] <jwalden> on the plus side, I've discovered a test I'd written earlier doesn't meaningfully test what it was testing any more since the domain/uri->origin change
# [03:48] <Hixie> othermaciej: hm, we could send host and path information in the request
# [03:48] <jwalden> I think I can use document.domain and some hacks to make it meaningful again
# [03:48] <mcarter> othermaciej, thats exactly my earlier reason for why it should support cookies
# [03:48] <Hixie> othermaciej: which would get us uri addressibility
# [03:48] <othermaciej> what I'd like to do is open http://www.mychatservice.com/messagestream/othermaciej
# [03:48] <Hixie> othermaciej: (in the same way that web servers do)
# [03:48] <othermaciej> and have that be a two-way full duplex connection
# [03:48] <mcarter> I see it like this, you should make a standard http request with a URL and headers, include an Upgrade: tcp/1.0 header
# [03:48] <othermaciej> that follows the same-origin security model
# [03:48] <Hixie> othermaciej: http is not a full-duplex protocol. we can never get this for an http://... uri
# [03:48] <mcarter> the server can repond acknowledging the upgrade or not
# [03:49] <othermaciej> and sends my cookies
# [03:49] <othermaciej> Hixie: http supports on-the-fly conversion to other protocols (TLS upgrade) and custom methods that do whatever you want (which can tunnel through a proxy via CONNECT)
# [03:50] <Hixie> othermaciej: in theory, sure
# [03:50] <mcarter> Hixie, you can get this for an http:// uri though. just have an http handhsake with an upgrade header
# [03:50] <Hixie> othermaciej: but i'm not writing an http server just so i can send messages back and forth
# [03:50] <othermaciej> I don't know whether it is viable to do this in practice
# [03:50] <othermaciej> that is why I think a proof of concept that integrates with a real server would be informative
# [03:50] <othermaciej> Hixie: neither should you have to write an http server just so you can publish hypertext documents, but fortunately that problem has been solved for you
# [03:51] <Hixie> the original use case i had for this -- my train server -- was a perl script about 50 lines long, most of which was infrastructure to talk to the machine's serial port to control my trains
# [03:51] <Hixie> adding a compliant http server to this would be many more than 50 lines
# [03:51] <Hixie> 1000 maybe
# [03:51] <mcarter> Hixie, don't think of it like that. Choose a subset of http that an existing server would understand as http
# [03:51] <othermaciej> I don't think a train server is a very interesting use case compared to things like chat or other notification streams
# [03:51] <Hixie> mcarter: then it's not conforming
# [03:52] <Hixie> mcarter: or it's not http
# [03:52] <mcarter> Hixie, but thats okay
# [03:52] <mcarter> Hixie, i'm saying, our protocol should NOT be http
# [03:52] <Hixie> mcarter: what's the point of pretending to use http if it's not http?
# [03:52] <Hixie> i'd still have to support http if you handshake on http first
# [03:52] <othermaciej> writing an auth mechanism that works securely without leveraging the http-related infrastructure would take more than 50 lines too
# [03:52] <mcarter> Hixie, so existing servers give back reasonable responses, and you can still do load balancing and authentication with existing methods
# [03:52] <mcarter> Hixie, we handshake on a *subset* of http
# [03:53] <othermaciej> most interesting two-way notification streams would require authentication and would be offered by web services that are already doing auth via http cookies
# [03:53] <Hixie> mcarter: and what happens if someone steps outside that subset? it's still conforming http, so i still have to handle it somehow.
# [03:53] <mcarter> Hixie, if the server steps out of our http-subset, then consider it an invalid tcp connection response and fire an onclose back
# [03:54] <Hixie> mcarter: i don't consider that acceptable
# [03:54] <mcarter> Hixie, the client won't step out because thats what we are trying to standardize. If it does, the server can just give back a 400 or something
# [03:54] <Hixie> mcarter: either it's http or it isn't
# [03:54] <mcarter> Hixie, why should it be one or the other though?
# [03:54] <Hixie> mcarter: what if i connect to the server and do a HEAD request? or have a Host header that's wrong? or whatever
# [03:55] <Hixie> mcarter: because profiling specifications because they're "too hard" isn't how you get interoperability
# [03:55] <mcarter> our tcpconnection spec can say that you can't use a HEAD request. If you do, the server can respond however it wants because its not a tcpconnection handshake
# [03:55] <othermaciej> I think replying with a 501 would be valid
# [03:55] <othermaciej> (are there any methods that HTTP requires be supported on any resource?)
# [03:56] <Hixie> so now i have to actually check the method
# [03:56] <Hixie> which is imho ridiculous given that what i want to do is just open a socket
# [03:56] * Joins: Thezilch (n=fuz007@cpe-76-170-22-23.socal.res.rr.com)
# [03:56] <mcarter> Hixie, let me put together an example of this before you pass judgement on how hard it would be
# [03:57] <Hixie> people are going to just skip the steps that aren't required, and you'll end up with servers that open tcp connections for HEAD requests with no UPGRADE or whatever
# [03:57] <othermaciej> I don't think "model train controller" is the common use case
# [03:58] <othermaciej> many interesting use cases require authentication
# [03:58] <Hixie> the train controller required authentication too, actually
# [03:58] <othermaciej> chat, calendar event notification stream, notification stream of twitter messages posted by my contacts
# [03:58] <Hixie> just send the cookie down the pipe
# [03:58] <Hixie> what's the problem with that?
# [03:59] <othermaciej> prevents use of httpOnly cookies to mitigate cookie stealing attacks
# [03:59] <othermaciej> (assuming you are sending the cookie for a different site)
# [03:59] <mcarter> Hixie, also you couldn't have an auth reverse proxy that checks the cookie on the way in to perform authentication
# [03:59] <othermaciej> and then the server and the site vending the cookie have to communicate out of band
# [03:59] <othermaciej> to figure out if the cookie is valid
# [04:00] <Hixie> actually sending third-party cookies to identify the user to a host that's not from the same origin would be an interesting problem
# [04:00] <Hixie> same problem we have with XXX
# [04:00] <Hixie> maybe whatever solution we come up with for XXX can apply here
# [04:01] <Hixie> we could certainly define the api in such a way that cookies and http auth credentials are also sent down the pipe in the handshake
# [04:01] <Hixie> without leveraging the six ton http server
# [04:02] <Facedown> Is there any point to using the type attribute of the script element?
# [04:02] <Hixie> Facedown: not really
# [04:02] <Facedown> I know language is deprecated and type="text/javascript" doesnt really have any effect
# [04:02] <mcarter> Hixie, is there a reason not to arrange that data in a way that looks as close to http as possible, so as to avoid confusing intermediaries?
# [04:02] <Facedown> I guess people just put it there so there's at least one attribute, heh
# [04:03] <Hixie> mcarter: i don't mind it looking like HTTP so long as it isn't HTTP
# [04:03] <Facedown> Oh yeah, the validator and spec do say its required in strict though
# [04:03] <Hixie> Facedown: in html5 it's optional
# [04:03] * Quits: shepazu (n=schepers@123.127.99.15)
# [04:03] <Facedown> but isnt there a more correct value? like text/ecmascript?
# [04:03] <Hixie> Facedown: text/javascript is the right value
# [04:03] <Facedown> since javascript isnt the real name
# [04:03] <Facedown> hm
# [04:03] <Facedown> err, application/javascript
# [04:03] <Facedown> http://www.ietf.org/rfc/rfc4329.txt
# [04:04] <Facedown> someone told me about this.. not even sure about it
# [04:05] <mcarter> So what information have we identified so far that we need in the handshake?
# [04:05] <mcarter> 1) Host header, 2) URI, 3) Cookies, 4) referrer
# [04:07] <jacobolus> Facedown: you can just leave it off
# [04:08] <jacobolus> Facedown: all the browsers will know it's javascript
# [04:08] <jacobolus> in html5, it is optional
# [04:08] <jacobolus> so if you use an html5 conformance checker, it will be fine
# [04:09] <jacobolus> Facedown: there's no compelling reason to include it, and it just adds extra characters to your file
# [04:10] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
# [04:14] <jacobolus> Hixie: why are you so afraid of browsers sending bizarre parts of HTTP as part of this handshake?
# [04:14] <jacobolus> Hixie: aren't there plenty of obscure HTTP features ignored by existing web servers?
# [04:15] * Joins: MikeSmith (n=MikeSmit@123.127.99.32)
# [04:15] <Hixie> jacobolus: i'm worried about someone browsing to that URL and getting back something that is an infinite connection, yes
# [04:15] <Philip`> jacobolus: There are plenty of web servers that break on non-obscure features like HEAD, and it might be nice to not encourage that
# [04:15] <Hixie> anyway, bbiab
# [04:16] <jacobolus> Hixie: I see. it seems like that could be avoided
# [04:17] * Quits: weinig_ (n=weinig@nat/apple/x-acc79214e0951da7)
# [04:17] <mcarter> Hixie, we could use something like OPTIONS as our handshake method... something that a user will never cause to be sent just by browsing
# [04:18] <Philip`> mcarter: What would the server do when the user just sends a GET?
# [04:19] <mcarter> Philip`, send back either a 404, 400, or some status code as indicated in our tcp handshake spec
# [04:20] <mcarter> (while '\r\n\r\n' not in self.buffer) { self.buffer += sock.recv() }; try { assert buffer.startswith('OPTIONS') } catch { sock.send('HTTP/1.x 400 Invalid Handshake\r\n\r\n') }
# [04:20] <mcarter> or something like that
# [04:21] <Philip`> (That try/assert/catch thing looks like an awkward way of writing 'if' :-) )
# [04:27] * Quits: andersca (n=andersca@nat/apple/x-ac6e736ca436838f) (Read error: 110 (Connection timed out))
# [04:28] * Joins: weinig_ (n=weinig@nat/apple/x-6f49018ca24cddb8)
# [04:29] <mcarter> Philip`, heh, my only point is that you can just assume the request looks a certain way and just catch any errors if the assumption is wrong
# [04:36] * Joins: shepazu (n=schepers@123.127.99.15)
# [04:41] * Quits: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk) ("Ex-Chat")
# [05:05] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
# [05:24] * Quits: othermaciej (n=mjs@17.203.15.181)
# [05:50] * Quits: weinig (n=weinig@17.203.15.172)
# [05:50] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [05:50] * Quits: weinig_ (n=weinig@nat/apple/x-6f49018ca24cddb8)
# [05:50] * Joins: othermaciej (n=mjs@17.203.15.181)
# [05:52] * Quits: shepazu (n=schepers@123.127.99.15)
# [05:54] * Joins: shepazu (n=schepers@123.127.99.15)
# [05:58] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
# [06:00] * Quits: shepazu (n=schepers@123.127.99.15)
# [06:02] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
# [06:14] * Quits: MikeSmith (n=MikeSmit@123.127.99.32) (Read error: 110 (Connection timed out))
# [06:43] <Hixie> mcarter: why would people not just do (while '\r\n\r\n' not in self.buffer) { self.buffer += sock.recv() }; without the other checks?
# [06:46] <mcarter> Hixie, I see, you're worried about server implementors sending back the wrong thing thus making it possible for a browser to directly connect to a tcp handshake server and get an infinite response
# [06:47] <mcarter> Hixie, in which case, the proper response for a tcp handshake should be to send back a content-length: 0 as part of the headers
# [06:47] <Hixie> i'm worried about any protocol that relies on the author having to do something which they don't get any direct benefit from
# [06:47] <Hixie> because the web shows that authors will not bother
# [06:48] <jacobolus> Hixie: how can you possibly prevent that?
# [06:48] <mcarter> its not clear to me that its a real problem for them to actually ignore the handshake's exact protocol
# [06:48] <Hixie> jacobolus: by not requiring them to do anything other than what they need
# [06:48] <mcarter> if they ignore the protocol, and if someone manages to point an http browser at the tcp server, then shouldn't they get an erroneous response?
# [06:48] <Hixie> mcarter: i'm not writing a spec that says "you must do x" if not doing x will work just as well
# [06:49] <jacobolus> Hixie: you're basically afraid of web servers implementing things such that web browsers could hang. but it seems like that becomes a browser bug, no?
# [06:49] <jacobolus> (hang or use up resources or whatever)
# [06:49] <Hixie> my concern isn't a specific concern, it's a generic one of not wanting to require things that the author gets no benefit from
# [06:50] <mcarter> Hixie, so i say we require a single thing from server implementors
# [06:51] <mcarter> Hixie, and that is, that they send back a specific http response as their half of the handshake
# [06:51] <jacobolus> the author's benefit is that he'll know the browser is actually speaking the proper protocol. is that not enough benefit to properly implementing the handshake?
# [06:51] <mcarter> Hixie, and if they don't send back that response, then the browser rejects the handshake
# [06:51] <Hixie> jacobolus: obviously not, just look at what authors do with html
# [06:52] <Hixie> mcarter: yup, we can do that. but that means what you described above won't happen
# [06:53] <mcarter> Hixie, that was an example to othermaciej how we can prevent random web pages from appearing to hang when users mistakenly navigate to them. the better solution is to require a Content-Length: 0 header, or even a couple dozen bytes in the body which are an error message "You shouldn't be seeing htis page... Go somewhere else."
# [06:53] <mcarter> Hixie, but i see where you're coming from
# [06:54] <othermaciej> mcarter: already now if you navigate your browser to a persistent XHR stream it may appear to hang
# [06:54] <othermaciej> so I do not see solving this problem as essential
# [06:55] <othermaciej> if you browse to reasources not meant to be browsed to directly, weird shit may happen, tough cookies
# [06:55] <mcarter> othermaciej, oh, that wasn't an example for you. it was for Hixie. sorry for the mixup
# [06:56] <othermaciej> perhaps Hixie will agree with my comments as well, since they reduce the burden of what is required on server implementors
# [06:58] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
# [06:58] <Hixie> i could see an argument for making the handshake look much more like http
# [06:59] <Hixie> but that would not work with proxies
# [06:59] <Hixie> and would not be http-over-port-80
# [06:59] <othermaciej> you'd have to use CONNECT to tunnel through proxies on the client side
# [06:59] <Hixie> and would in fact not seem to solve any of the purported problems with the current proposal
# [06:59] <mcarter> oh but it would. just make sure you send the CONNECT for the proxy
# [06:59] <Hixie> sure, but we can do CONNECT regardless of what else we do
# [07:00] <othermaciej> and it would solve the URI addressing, lack of cookies, and unable-to-use-web-security-model issues
# [07:00] <mcarter> I'm not clear what the purported problems are with the current proposal. I saw at least one problem, like the dns rebinding attack, and this solves it
# [07:00] <mcarter> Hixie, so CONNECT should happen in any case, and its not really an issue in the non/http discussion
# [07:01] <Hixie> right
# [07:01] <Hixie> it wouldn't solve the uri addressing really
# [07:01] <Hixie> unless we invent a new uri scheme
# [07:01] <mcarter> I'm not sure I follow
# [07:01] <Hixie> ok let me rephrase taht
# [07:01] <Hixie> it isn't necessary to solve the uri addressing issue, or the cookie issue, etc
# [07:02] * othermaciej waits for Hixie to expand on that
# [07:03] <Hixie> we can add Host:, Cookie:, etc, to any protocol
# [07:03] <Hixie> doesn't have to look like http
# [07:03] <mcarter> while they aren't absolutely critical issues to have full duplex communication, i think you can spend a little and get a lot by having the client provide the extra information, and format it like http.
# [07:03] <Hixie> i'm all for having that information
# [07:03] <Hixie> i'm just saying that has nothing to do with it being http or not
# [07:03] <Hixie> or http-like, rather
# [07:03] <mcarter> ok
# [07:04] <othermaciej> cookie depends on a host-port-scheme origin though
# [07:04] <mcarter> I think it would be good to look like http because then http parsing libraries would, out of the box, be able to parse it and extract that information. Furthermore, load balancers and authentication reverse proxies could be used AS IS
# [07:04] <othermaciej> so to share cookies with a web server you have to be on the same scheme and port
# [07:04] <mcarter> Hixie, furthermore, you avoid the HTTPS virtual hosting issue that was solved with TLS
# [07:05] <mcarter> Hixie, I'm not sure what the downside of making it look like http is
# [07:05] <othermaciej> I agree you can add Host:, URI-based addressing, and a version of Cookie: that is separate from http cookies to any protocol
# [07:05] <othermaciej> at some level of http-like feature additions it starts to look a lot like http though
# [07:05] <Hixie> othermaciej: yes, the cookies wouldn't get shared if you connected to another server (another port)
# [07:06] <Hixie> othermaciej: but how am i gonna get apache to give me the socket anyway?
# [07:06] <Hixie> mcarter: the only downside is that it's a lie and the httpwg will come and stone us
# [07:07] <mcarter> Hixie, I am suggesting that we make it VERY clear that we aren't HTTP, rather a subset used for TCP handshakes
# [07:07] <othermaciej> Hixie: with a custom method or similar mechanism one could presumably make an apache module (which is why I think making one would be an interesting proof-of-concept excercise)
# [07:07] <mcarter> Hixie, they can't be seriously upset if another protocol borrows some formatting from http
# [07:07] <Hixie> mcarter: hahaha
# [07:07] <Hixie> mcarter: i see you haven't spent much time working with standards committees
# [07:07] * Joins: roc (n=roc@121-72-179-147.dsl.telstraclear.net)
# [07:08] <Hixie> othermaciej: making an apache module is more than 10 lines of perl
# [07:08] <Hixie> othermaciej: though i agree that in this case it would be ok
# [07:08] <othermaciej> Hixie: sure, but if you don't want to share the port the apache server has bound, you would not need the module
# [07:08] <Hixie> othermaciej: as it would allow it for the big players or people using server extensions
# [07:08] <Hixie> othermaciej: right
# [07:08] <othermaciej> if the http subset for the handhsake is simple enough
# [07:08] <Hixie> othermaciej: yeah that makes sense
# [07:08] <Hixie> i'm ok with that
# [07:10] <mcarter> Hixie, couldn't we call this TCP over HTTP? The server isn't required to go support all of http, though its welcome to
# [07:10] <Hixie> mcarter: optional features are bad for interop
# [07:10] <mcarter> Hixie, as far as I can tell, this is almost the EXACT use case for which they added the upgrade header
# [07:10] <othermaciej> mcarter: I think it would be well advised to define what a server should do when it only supports the handshake subset of TCP
# [07:11] <othermaciej> er
# [07:11] <othermaciej> handshake subset of HTTP
# [07:11] <Hixie> mcarter: i agree that this is why upgrade exists
# [07:11] <Hixie> mcarter: but since we can't guarentee that people will test for it
# [07:11] <Hixie> mcarter: it doesn't really help us
# [07:11] <othermaciej> such as return a 501 error for any other request
# [07:11] <Hixie> we can't define what a "server should do"
# [07:12] <Hixie> when the server is written by random authors
# [07:12] <Hixie> it's akin to defining how you should use a dom api
# [07:12] <mcarter> Hixie, if someone writes a non-compliant http server that likes to always assume a connection is going to be upgraded, then how is that our problem, OR httpwg's problem?
# [07:12] <mcarter> Hixie, the same argument can be made against doing TLS with the upgrade header. Server implementors might just go an upgrade on their own without testing for it.
# [07:12] <Hixie> mcarter: sure
# [07:12] <Hixie> mcarter: i
# [07:12] <Hixie> er
# [07:13] <othermaciej> I think Hixie assumes writing this kind of server from scratch will be more common than writing full-fledged http servers
# [07:13] <Hixie> mcarter: i'm just saying it doesn't matter that upgrade exists :-)
# [07:13] <othermaciej> although there are quite a few http server implementations out there
# [07:13] <othermaciej> and usually their level of non-compliance is within tolerable limits for UAs
# [07:14] <othermaciej> (I wonder if there is a protocol-level HTTP Validator tool available)
# [07:14] <Hixie> let's just say http isn't how it would have been if i'd been writing the spec either :-)
# [07:16] <mcarter> Hixie, I'm still missing some of the logic. That is, the TLS spec went and used the upgrade header, even though server implementors of TLS might not have actually enforced that header and instead treated all requests like they were part of a TLS handshake. Now we're saying, lets follow suit and do exactly that with our tcp protocol. Which part of this will make the httpwg mad?
# [07:17] <Hixie> the part where you can connect to something that isn't an http server, send it something that looks exactly like an http response, and be compliant, despite the fact that the server doesn't know the first thing about http
# [07:17] <Hixie> i should clarify
# [07:17] <Hixie> that annoying the httpwg isn't necessarily a blocking problem
# [07:17] <Hixie> especially if there are compelling reasons to go this route, as there appear to be
# [07:19] <jacobolus> Hixie: I think you should go rewrite the HTTP spec, and get rid of all the confusing shit in it ;)
# [07:19] <Hixie> http5 is gsnedders' baby
# [07:19] <othermaciej> I am amazed at how technically obscure the http spec is, while at the same time being incredibly unclear on the most basic things
# [07:20] <jacobolus> mcarter has learned to love the http spec these last several months, right?
# [07:20] <jacobolus> he's been having fun writing things like proxies :)
# [07:20] <mcarter> Hixie, ok. in terms of explaining it in way that won't make anyone mad is this: HTTP Servers can also be HTTP/TCP servers if they support Upgrade: tcp. Similarly, anyone who wants to can go write an http or http/tcp server even if it isn't fully compliant (which http server is FULLY compliant anyway?)
# [07:21] <Hixie> othermaciej: like svg? :-D
# [07:21] <mcarter> at any rate, like I said before, I'll draw some documents up that outline some of this stuff
# [07:21] <Hixie> that'd be great
# [07:21] <Hixie> i think we've made major progress here
# [07:21] <mcarter> I sent an api change proposal in for TCPConnnection today, whenever you see it
# [07:21] <mcarter> it just suggests adding a connect() method, and an extra readyState
# [07:21] <jacobolus> yep. and then just make sure that HTTP/TCP is as minimal as possible. :)
# [07:22] <othermaciej> mcarter: I don't like explicit connect
# [07:22] * Joins: MikeSmith (n=MikeSmit@123.127.99.32)
# [07:22] <jacobolus> so that the 10-lines-of-perl constituency stays happy :)
# [07:23] <mcarter> othermaciej, the api change is mostly for the reason of re-using the TCPConnection objects much like we re-use XHR connections
# [07:23] <othermaciej> mcarter: because, first of all, reusing a connection is more confusing than helpful
# [07:23] <jacobolus> Hixie: do you have docs about your train set thing?
# [07:23] <othermaciej> mcarter: and second, because it adds an additional opportunity to use the API wrong, since you can accidentally make calls before connecting
# [07:23] <othermaciej> the current API does not have the possibility of making that mistake
# [07:24] <mcarter> othermaciej, Also, I don't fully feel comfortable with the idea that I must possess deep understanding of javascript concurrency to know when I need to attach the callbacks
# [07:24] <othermaciej> mcarter: ain't no such thing as javascript concurrency
# [07:24] <mcarter> othermaciej, if i create a TCPConnection object, at what point does it *Actually* initiate the connection? when my function that created it returns? when the function that called it returns?
# [07:24] <Hixie> jacobolus: i don't believe so
# [07:25] <mcarter> othermaciej, indeed, but it doesn't seem wise to tie your apis to the idea that there is no concurrency in javascript
# [07:25] <mcarter> othermaciej, at least not where its easy to avoid doing so
# [07:25] <othermaciej> mcarter: as with XHR, you will not in fact get callbacks for network activity until the current script execution (whether <script>, event or timer initiated) finishes
# [07:25] <othermaciej> (well, as with async XHR)
# [07:25] <othermaciej> I don't think it is possible to safely change this rule about callbacks for network activity in any case
# [07:25] <mcarter> othermaciej, so, I suppose we aren't allowing for synchronous tcp connection, ever?
# [07:25] <othermaciej> but yes, programming in the browser there is an implicit "event loop"
# [07:26] <othermaciej> mcarter: no way
# [07:26] <Hixie> good lord no
# [07:26] <othermaciej> or at least, over my dead body
# [07:26] <Hixie> no synchronous anything over the network
# [07:26] <jacobolus> yes, that sounds like a bad idea
# [07:26] <Hixie> i don't know if i'd defend against that with my life, per se
# [07:26] <Hixie> but still
# [07:26] <mcarter> I certainly wouldn't want such a thing, but aren't there being arrangements made for threading in some future javascript?
# [07:26] * Joins: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net)
# [07:26] * Quits: MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net) (Remote closed the connection)
# [07:27] <othermaciej> mcarter: even with threads, I am not sure synchronous networking is particularly valuable
# [07:27] <mcarter> othermaciej, I certainly don't want to argue that point
# [07:27] <othermaciej> for exaple, Gears has its workers and they are adding async networking only, I believe (their HTTPRequest thing)
# [07:29] <jacobolus> mcarter: is there any other particular reason to not connect immediately?
# [07:29] <jacobolus> mcarter: why does someone need to add a bunch of callbacks at indeterminate times, then sometime way later actually connect?
# [07:29] <mcarter> besides re-use of the connection object, as a programmer it just seems strange to me to have something where the constructor hits the network. particularly in the context of this javascript event loop -- I can see someone making a mistake about when they should attach the callback
# [07:30] <othermaciej> mcarter: you can't reuse a socket
# [07:30] <othermaciej> or a file descriptor
# [07:30] <othermaciej> or a C stdio FILE*
# [07:30] <othermaciej> or a perl file handle
# [07:30] <mcarter> i get your point
# [07:30] <mcarter> if anything thats an argument against re-using the XHR request object, imo
# [07:31] * Quits: Facedown (n=HELLO@c-68-48-58-38.hsd1.md.comcast.net) (Read error: 110 (Connection timed out))
# [07:31] <Hixie> xhr is badly designed
# [07:31] <othermaciej> yes, but we have to support that for legacy compatibility
# [07:31] <othermaciej> XHR is not what I would have designed
# [07:31] <Hixie> basically anything i didn't invent is badly designed, it's really very simple
# [07:31] * Hixie ducks
# [07:31] <mcarter> haha!
# [07:31] <othermaciej> plus anything you did invent
# [07:32] <othermaciej> but some things are more badly designed than others
# [07:33] <mcarter> Hixie, how did this happen, exactly?
# [07:33] <jacobolus> Hixie: you need to speed up your pace of invention then
# [07:34] <Hixie> mcarter: which?
# [07:34] <mcarter> Hixie, i mean, you seem to be in a position of some power over the browsers. I mean, i see the IE8 team emailing you about postMessage and such
# [07:34] <mcarter> it seems so unprecedented
# [07:34] <mcarter> (I think its great... a vast improvement)
# [07:36] <Hixie> mcarter: i've only got as much power as they give me
# [07:36] <Hixie> mcarter: my secret is giving them mostly what they want
# [07:36] <Hixie> oh and doing a lot of work
# [07:36] <mcarter> Is this your day job?
# [07:36] <Hixie> people tend to defer to whoever is actually doing the work
# [07:37] <Hixie> it's easier than doing it themselves
# [07:37] <Hixie> mcarter: yes, google pays me to edit html5 full time
# [07:37] <othermaciej> html5 has turned out to be an area where doing things through standards is less painful than just inventing proprietary features
# [07:38] <othermaciej> this is not always the case with web standards
# [07:38] <Hixie> yeah
# [07:38] <Hixie> css being the prime example these days
# [07:38] <othermaciej> I predict everything hyatt announced css-wise for the past 6 months will still be in committee 5 years from now
# [07:39] <Hixie> unless someone writes a spec yes
# [07:39] <othermaciej> I gotta head home
# [07:39] <othermaciej> later folks
# [07:39] <mcarter> whats the timeframe with html5? will it continue to be continuously updated?
# [07:39] <Hixie> later
# [07:39] * Quits: othermaciej (n=mjs@17.203.15.181)
# [07:39] <Hixie> mcarter: http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE
# [07:40] <mcarter> oh wow
# [07:40] <mcarter> thats a long time line
# [07:41] <jacobolus> Hixie: so will there be something beyond html5 by halfway through that process?
# [07:41] <Hixie> maybe
# [07:41] <Hixie> i don't expect to do html6
# [07:41] <Hixie> i mostly started working on html5 because at the time, html was the spec in most dire need of work
# [07:41] <jacobolus> right
# [07:42] <jacobolus> so do you think all of the recent webkit css changes will actually be picked up by other browsers?
# [07:42] <jacobolus> or will they remain limited to dashboard widgets, etc.
# [07:42] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
# [07:42] <roc> some of them I want to implement in Gecko
# [07:42] <roc> others I don't
# [07:42] <jacobolus> Hixie: what is in next-most-dire need?
# [07:43] <Hixie> jacobolus: probably DOM Core, CSS, and HTTP. And SVG.
# [07:43] <roc> fortunately the ones I want are the ones Apple is producing draft specs for
# [07:43] <jacobolus> svg isn't a lost cause? :p
# [07:43] <Hixie> css would be tough to fix because it has a large political quagmire around it
# [07:43] <Hixie> svg too
# [07:44] <Hixie> http could probably be fixed by ignoring the httpwg without too much fallout
# [07:44] <jacobolus> how would anyone possibly fix http?
# [07:44] <jacobolus> what could be done?
# [07:44] <Hixie> dom core would be the easiest to fix
# [07:44] <jacobolus> yes
# [07:44] <Hixie> well, by "fix" i mean "write a real spec"
# [07:44] <Hixie> that defines error handling, actual behaviour, etc
# [07:44] <jacobolus> what's broken about DOM core now?
# [07:44] <Hixie> and strips all the crap
# [07:44] <Hixie> jacobolus: the DOM Core spec is far too vague
# [07:44] <Hixie> in fact, all the DOM specs are too vague
# [07:45] <jacobolus> are the implementations vastly inconsistent then?
# [07:45] <jacobolus> while still meeting the spec?
# [07:48] <roc> a lot of HTTP implementations are just plain broken
# [07:48] <roc> especially proxies
# [07:48] <roc> not much anyone can do about that
# [07:49] <Hixie> jacobolus: not especially more than html4 implementations were, but a vague spec means it's hard to write a new browser
# [07:49] <Hixie> and we need it to be possible to write new UAs so that we can have competition
# [07:49] <jacobolus> roc: yes, I was talking about DOM. I know http is nasty :)
# [08:07] * Joins: shepazu (n=schepers@123.127.99.15)
# [08:26] * gsnedders cradles his baby
# [08:26] <gsnedders> (seeming Hixie called it my baby)
# [08:40] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) (Read error: 110 (Connection timed out))
# [08:55] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [09:09] <roc> Ian, please lean on the GMail team to implement HTML5 link handler stuff
# [09:09] <roc> for mailto:
# [09:10] <roc> I really need it!
# [09:10] * gsnedders wants mid: support in Mail.app
# [09:11] <Hixie> roc: i expect they'll do it shortly after ff3 sips
# [09:11] <Hixie> ships
# [09:11] <roc> Yahoo's already done it :-(
# [09:12] <roc> FF3 has UI to select the handler and Yahoo's on it and Gmail isn't
# [09:13] * Quits: shepazu (n=schepers@123.127.99.15)
# [09:17] <Hixie> we don't, as a rule, pay much attention to what the competition does, or at least, we don't let it dictate policy :-)
# [09:17] * Quits: jwalden (n=waldo@RANDOM-SIX-THIRTY-TWO.MIT.EDU) (Read error: 104 (Connection reset by peer))
# [09:18] <gsnedders> Peh! You should! :P
# [09:18] * Joins: jwalden (n=waldo@RANDOM-SIX-THIRTY-TWO.MIT.EDU)
# [09:18] <gsnedders> Actually, I don't eat my own dogfood. I don't really pay attention to the httpbis wg
# [09:19] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [09:22] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [09:27] * Joins: tndH_ (i=Rob@adsl-87-102-32-128.karoo.KCOM.COM)
# [09:27] * tndH_ is now known as tndH
# [09:37] * Quits: MikeSmith (n=MikeSmit@123.127.99.32) (Read error: 110 (Connection timed out))
# [09:43] * Quits: roc (n=roc@121-72-179-147.dsl.telstraclear.net)
# [09:50] <annevk> I found http://www.htmlfive.net/ which just seems to be a rip of the WHATWG blog with the intention to make money out of it
# [09:51] <annevk> I found it through: http://www.whathuhstudios.com/press/2008/04/24/html5/
# [09:51] <Hixie> terrible
# [09:51] <annevk> I have the feeling you're being sarcastig :)
# [09:52] <Lachy> well, they've violated the copyright license
# [09:52] <Lachy> there's no mention of the MIT license anywhere and no attribution
# [09:53] <annevk> attribution is not required
# [09:54] <Lachy> actually, yes it is. At least in Australia it is because attribution is considered a basic moral right
# [09:54] * Joins: shepazu (n=schepers@123.127.99.15)
# [09:54] <Hixie> our goal with the whatwg blog is to get more people to know about stuff right?
# [09:55] <Lachy> unless otherwise stated by the creator, attribution is always required otherwise it's plagiarism
# [09:55] <annevk> Yeah, guess I was just upset it wasn't a genuine fansite :)
# [09:55] <Hixie> oh there's no doubt that this is immoral
# [09:55] <Hixie> but i recommend not worrying about it
# [09:56] <Lachy> I don't have a problem with them syndicating the posts. That's why we put a free license on it.
# [09:56] <Hixie> yeah but just copying them with no attribution or anything is just nasty
# [09:57] <Lachy> I will see if I can find contact information and ask them to give attribution
# [10:01] <Hixie> ask them to buy us video games with some of the money they make, too
# [10:03] <Lachy> I can't seem to find contact info. Though, there is only one site listed in the blog roll, I'm not certain that he's the owner of the site.
# [10:03] <Lachy> WHOIS info for the domain only shows dreamhost contact info.
# [10:07] <Lachy> wow, that's a useless contact form! http://blog.nprignano.com/contact/message Not even a text box :-(
# [10:07] <hsivonen> it seems to me that the foremost practical concern is getting Google and Technorati consider it a splog
# [10:07] <hsivonen> perhaps they both already do, because it isn't showing up on my vanity feeds
# [10:08] <Lachy> hsivonen, the domain was only just registered 2 days ago
# [10:08] <Lachy> so it will take a few weeks before it shows up in google
# [10:08] <hsivonen> annevk: what's the chance of getting an XML5 tokenizer spec as a delta spec over the HTML5 tokenization spec?
# [10:09] <othermaciej> delta specs suck
# [10:09] <hsivonen> othermaciej: they do, but it seems to me that XML5 and HTML5 will share so much tokenization code that I don't want to write another tokenizer from scratch
# [10:10] <othermaciej> hsivonen: well I don't know what to expect from XML5 so I can't predict if that will be sensible
# [10:11] <othermaciej> would it, for example, accept unquoted attribute values?
# [10:13] <hsivonen> othermaciej: it seems to me that ideally, the only new states would be for the internal subset and PIs
# [10:13] <hsivonen> and otherwise the delta would be where errors fire
# [10:14] <hsivonen> of course, ideally ideally, the internal subset would be swallowed by a black hole
# [10:14] <othermaciej> well <foo/> would have to do something different, as well
# [10:14] <othermaciej> and it has to recognize <![CDATA[
# [10:15] <hsivonen> othermaciej: but we already have those in the HTML5 tokenizer now
# [10:15] * jwalden finishes rewriting postMessage for the third time
# [10:15] <jwalden> "rewriting", that is
# [10:16] <jwalden> bloody spec changes :-)
# [10:16] <othermaciej> interesting
# [10:17] <othermaciej> I still hate delta specs though
# [10:17] <othermaciej> yeah we have to fix WebKit's postMessage now
# [10:17] <hsivonen> othermaciej: well if you can get Hixie to integrate XML5 tokenization into the HTML5 tokenizer spec...
# [10:18] <jwalden> actually, fixing the implementation's comparatively easy, it's all those stupid tests I've written that are taking the lion's share of the time to change
# [10:18] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
# [10:18] <jwalden> and all the tests others have written that use postMessage since it was introduced
# [10:18] <jwalden> ;-)
# [10:18] * jwalden makes note never to write tests ever again
# [10:19] <jwalden> all they cause is more work
# [10:19] <Hixie> :-/
# [10:19] <jwalden> I kid, I kid!
# [10:19] * jwalden channels the Dread Pirate Roberts
# [10:20] <othermaciej> never go in against a Swissilian when specs are on the line
# [10:20] <jwalden> haha, haha, ha-
# [10:23] <hsivonen> Hixie: so far, the YSTEM and UBLIC cases have translated into states very nicely
# [10:23] <hsivonen> Hixie: I expect breaking up the entity stuff into states to be a tad ugliers
# [10:23] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
# [10:23] <hsivonen> uglier
# [10:29] * Quits: Lachy (n=Lachlan@ti200710a340-1179.bb.online.no) ("Leaving")
# [10:30] <hsivonen> I wonder if there are Java to C++ source level translators
# [10:37] <hsivonen> does anyone know how IBM maintains their dual Java/C++ libraries?
# [10:38] <othermaciej> 3 levels of committee review for every checkin?
# [10:39] <hsivonen> othermaciej: could be :-/
# [10:47] <mpt> krijn, is your IRC logging software publicly available?
# [10:47] * Joins: ROBOd (n=robod@89.122.216.38)
# [10:47] <krijn> mpt: nope, sorry
# [10:48] <krijn> mpt: I'm too ashamed about the source code :)
# [10:48] <krijn> And it's not really logging software, the logging is done by mIRC
# [10:48] <krijn> I only parse the logfiles with some PHP
# [10:48] <krijn> Hence the shame ;)
# [10:48] <mpt> ah
# [10:48] * Joins: roc (n=roc@121-72-179-147.dsl.telstraclear.net)
# [10:53] * Joins: MikeSmith (n=MikeSmit@123.127.99.32)
# [10:59] * Quits: shepazu (n=schepers@123.127.99.15)
# [11:03] * Joins: webben (n=benh@nat/yahoo/x-d0a7a35d1a55ec98)
# [11:06] <Philip`> http://blog.facebook.com/atom.php - feeds are always more fun when you stick random binary garbage in them
# [11:08] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
# [11:12] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
# [11:18] * Joins: shepazu (n=schepers@123.127.99.15)
# [11:28] * Joins: wakaba__ (n=w@151.164.210.220.dy.bbexcite.jp)
# [11:28] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
# [11:28] <sverrej> rn
# [11:28] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
# [11:41] * Quits: MikeSmith (n=MikeSmit@123.127.99.32) ("Less talk, more pimp walk.")
# [11:44] * Quits: jwalden (n=waldo@RANDOM-SIX-THIRTY-TWO.MIT.EDU) (Remote closed the connection)
# [11:46] * Quits: wakaba_ (n=w@11.164.210.220.dy.bbexcite.jp) (Read error: 113 (No route to host))
# [11:48] * Quits: shepazu (n=schepers@123.127.99.15)
# [11:57] * Quits: mcarter (n=mcarter@pool-72-87-174-7.plspca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
# [12:01] * Quits: Thezilch (n=fuz007@cpe-76-170-22-23.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
# [12:07] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
# [12:12] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
# [12:46] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [12:48] * Quits: roc (n=roc@121-72-179-147.dsl.telstraclear.net)
# [13:31] * Quits: webben (n=benh@nat/yahoo/x-d0a7a35d1a55ec98)
# [13:33] * Joins: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
# [13:33] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [13:39] * Joins: myakura_ (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
# [13:39] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [13:44] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
# [13:55] * Quits: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
# [13:57] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [14:04] * Joins: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk)
# [14:31] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [14:38] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Remote closed the connection)
# [14:48] <hsivonen> http://lists.w3.org/Archives/Public/www-validator/2008Apr/0136.html
# [14:54] * Joins: webben (n=benh@nat/yahoo/x-db23f3b6a562a74f)
# [14:54] <hsivonen> aside: Typinator is awasome for refactoring code
# [14:54] <hsivonen> awesome
# [14:55] * Quits: webben (n=benh@nat/yahoo/x-db23f3b6a562a74f) (Client Quit)
# [14:58] * Joins: webben (n=benh@nat/yahoo/x-ffc8c38bbca3ce9e)
# [15:22] * Joins: ROBOd (n=robod@89.122.216.38)
# [15:35] * Joins: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
# [15:42] * Joins: phsiao (n=shawn@nat/ibm/x-0234d479eec745e0)
# [15:48] * Joins: jgraham (n=james@195.58.126.131)
# [15:48] * Quits: myakura_ (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
# [16:10] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [16:10] * Joins: qwert666 (n=qwert666@acbg217.neoplus.adsl.tpnet.pl)
# [16:11] * Joins: sverrej (n=sverrej@89.10.27.86)
# [16:17] * Joins: ROBOd (n=robod@89.122.216.38)
# [16:18] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [16:22] * Quits: jgraham (n=james@195.58.126.131) ("I'll hit the bottom and escape")
# [16:22] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
# [16:48] <hsivonen> aargh. I regressed &noti;
# [16:48] * hsivonen doesn't like &noti;
# [16:48] <Lachy> Hixie, it would help if the spec had links from each section in the single-page version of the spec to same section in the multipage version.
# [16:49] <Lachy> that way, when I want to give a link to someone, I don't need to send them to the full size spec, or take the time to manually find the section in the multipage version
# [16:53] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
# [16:56] <Lachy> hsivonen, there is no &noti; listed in the spec. Did you mean ∉?
# [16:57] <hsivonen> Lachy: no, I meant &noti;
# [16:57] <Lachy> Hixie, ¬ is listed twice in the table of entities
# [16:57] <hsivonen> Lachy: I've fixed it now
# [16:57] <hsivonen> Lachy: &noti; is a tricky error cases
# [16:57] <hsivonen> s/cases/case/
# [16:58] <Lachy> ok
# [16:59] <Philip`> Do the new entities introduce any more cases where one entity is a prefix of another?
# [16:59] <hsivonen> Philip`: I don't know. I'm keeping my head in sand and hoping they go away.
# [17:11] <Lachy> Philip`, do you mean like ¬ ∉ &notinva; &notinvb; &notinvc; &notni; etc...?
# [17:12] <Lachy> looks like there are several, and I only looked in one small section of the table
# [17:13] <takkaria> Lachy: &not and ¬ are not the same entity
# [17:13] <takkaria> well, they are, but the duplication is intentional
# [17:13] * Joins: mcarter (n=mcarter@pool-72-87-174-18.plspca.dsl-w.verizon.net)
# [17:13] <Lachy> really?
# [17:13] <takkaria> Lachy: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tokenisation.html , the "anything else" section at the end
# [17:13] <takkaria> yeah
# [17:13] <Lachy> oh, crap. maybe it would help if I actually read the spec one day
# [17:15] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
# [17:16] <Lachy> takkaria, which "anything else" section are you referring to?
# [17:17] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [17:20] <takkaria> Lachy: very end of that page
# [17:23] <Lachy> ok. I think the duplication is annoying. Surely there's a way to write the spec such that you don't need to have the same entity listed twice with and without the semi-colon
# [17:23] <takkaria> there would be if every entity was allowed to leave out the semicolon
# [17:24] <takkaria> but afaik, that's not the case
# [17:25] <Lachy> couldn't we add a 3rd column to the table that indicated whether or not a semi-colon was required
# [17:25] <Lachy> for the purpose of parsing
# [17:25] <Lachy> not for conformance
# [17:26] <takkaria> I'm not in favour of that because it makes it harder to build a list of entities for implementations
# [17:27] <takkaria> automatically, that is
# [17:27] * Philip` agrees with takkaria
# [17:27] <Philip`> It's nice and easy to just use a regexp to convert the table into a list of entity strings, and it'd need an extra line of code if the semicolonity was a separate column
# [17:28] <takkaria> oh, you use a regex? I use xslt. :)
# [17:28] <Philip`> Yuck :-p
# [17:29] <takkaria> only 11 lines of it, mind
# [17:30] <Philip`> I'm guessing mine was only a single line, because I can't see that I saved the code in a file anywhere
# [17:32] <Lachy> ok, fine. I'll put a table targetted at authors in the HTML5 author guide which lists them only once
# [17:33] <Philip`> A table for authors should show what the character looks like, too
# [17:33] <Lachy> yep, it will list everthing about the character
# [17:33] * Philip` wonders if the characters could be categorised into usefulness, rather than having the standard unreadable big list
# [17:34] <Lachy> code point, character name, link to further info about the character, numeric (hex and decimal) character refs, etc.
# [17:35] <Lachy> they were grouped into categories in HTML4
# [17:35] <Philip`> Might be nice to not scare authors by having a really wide table, too :-)
# [17:36] <takkaria> Lachy: how about including the character the entity represents too?
# [17:36] <Lachy> I could make it interactive and let authors show and hide columns they want to see
# [17:37] <Lachy> takkaria, yeah, Philip` already mentioned that
# [17:37] <takkaria> oh, I missed that. :)
# [17:37] <Lachy> see, I'm not the only one who doesn't read around here :-P
# [17:42] <takkaria> I only remember that because it was around the time I got interested in html5 parsing and it was the only bit of the conversation I understood
# [17:53] <hsivonen> Lachy: the entity table is fine as is
# [17:54] <hsivonen> that is, with duplication
# [17:54] <hsivonen> Lachy: making the table neater in spec would only cause more opportunity for implementation error
# [17:55] <Lachy> hsivonen, Philip` and takkaria already told me that.
# [17:57] * Quits: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
# [18:02] <takkaria> there seems to be a "no-one is reading what anyone else has said" bug going round today
# [18:02] <takkaria> let's just hope Hixie doesn't get it
# [18:04] <Philip`> Hey, has anyone noticed the entity table lists "not" twice?
# [18:06] * Joins: eseidel_ (n=eseidel@72.14.228.1)
# [18:10] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
# [18:10] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
# [18:11] * Joins: sverrej (n=sverrej@89.10.27.86)
# [18:18] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
# [18:22] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [18:22] * Quits: Lachy (n=Lachlan@85.196.122.246) (Remote closed the connection)
# [18:22] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [18:27] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
# [18:30] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
# [18:38] * Joins: jgraham (n=jgraham@81-86-219-23.dsl.pipex.com)
# [18:48] * Joins: maikmerten (n=maikmert@L9848.l.pppool.de)
# [18:53] * Joins: jruderman_ (n=jruderma@c-67-180-174-213.hsd1.ca.comcast.net)
# [18:53] * Quits: jruderman (n=jruderma@c-67-180-174-213.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
# [18:53] * Quits: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk) ("Ex-Chat")
# [19:02] * Joins: weinig (n=weinig@17.203.15.172)
# [19:06] * Joins: KevinMarks (n=KevinMar@nat/google/x-38a4078df99effbc)
# [19:09] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [19:16] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
# [19:28] * Quits: maikmerten (n=maikmert@L9848.l.pppool.de) (Read error: 113 (No route to host))
# [19:29] * Joins: maikmerten (n=maikmert@T6ea6.t.pppool.de)
# [19:50] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
# [19:53] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [19:56] * Joins: Lachy_ (n=Lachlan@85.196.122.246)
# [19:57] * Quits: Lachy (n=Lachlan@85.196.122.246) (Nick collision from services.)
# [19:57] * Lachy_ is now known as Lachy
# [20:23] * Quits: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk) ("leaving")
# [20:23] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
# [20:29] * Quits: eseidel_ (n=eseidel@72.14.228.1)
# [20:29] * Quits: webben (n=benh@nat/yahoo/x-ffc8c38bbca3ce9e) (Connection timed out)
# [20:30] * Joins: eseidel (n=eseidel@72.14.228.1)
# [20:36] * Joins: jwalden (n=waldo@STRATTON-THREE-THIRTY.MIT.EDU)
# [20:42] <mcarter> You know, if a TCPConnection constructor causes a network access, then prototype-based subclassing becomes impossible
# [20:44] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [20:45] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [20:58] * Joins: sverrej_ (n=sverrej@89.10.27.86)
# [21:03] * Joins: andersca (n=andersca@nat/apple/x-94a1acce4eb52cbb)
# [21:07] * Joins: Camaban (n=alee@85-211-183-116.dyn.gotadsl.co.uk)
# [21:10] * Quits: eseidel (n=eseidel@72.14.228.1)
# [21:15] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 113 (No route to host))
# [21:23] * Quits: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk) (Remote closed the connection)
# [21:29] * Quits: Camaban (n=alee@85-211-183-116.dyn.gotadsl.co.uk) (Read error: 110 (Connection timed out))
# [21:30] * Joins: Camaban (n=alee@85-211-107-199.dyn.gotadsl.co.uk)
# [21:34] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
# [21:37] * Quits: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk) (Client Quit)
# [21:37] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
# [21:42] * Quits: maikmerten (n=maikmert@T6ea6.t.pppool.de) ("Leaving")
# [21:48] * Quits: KevinMarks (n=KevinMar@nat/google/x-38a4078df99effbc) ("The computer fell asleep")
# [21:49] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
# [21:50] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [22:13] * Joins: Camaban_ (n=alee@85-211-226-53.dyn.gotadsl.co.uk)
# [22:17] * Quits: Camaban_ (n=alee@85-211-226-53.dyn.gotadsl.co.uk) (Read error: 104 (Connection reset by peer))
# [22:20] * Quits: Camaban (n=alee@85-211-107-199.dyn.gotadsl.co.uk) (Read error: 110 (Connection timed out))
# [22:22] * Joins: Camaban (n=alee@85-211-19-59.dyn.gotadsl.co.uk)
# [22:32] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
# [22:37] * Joins: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com)
# [22:46] * Philip` discovers that http://www.aaronsw.com/2002/diff/ quite badly fails to work
# [22:47] <Philip`> since it totally ignores element nesting, and just sticks <ins> and </ins> at pretty much arbitrary points in the document, which makes browsers cry
# [22:48] <Philip`> but http://htmlwg.mn.aptest.com/viewcvs/viewcvs.cgi/htmldiff/ actually works properly (and it doesn't make XHTML become ill-formed), which is nice, though the code's use of regexps for parsing looks a little dodgy
# [22:49] <Dashiva> Is there a "proper" way to <ins> the transition Apple <em>pie</em> -> Apple banana <em>pan pie</em>?
# [22:51] <Philip`> Is anything wrong with Apple <ins>banana </ins><em><ins>pan </ins>pie</em>?
# [22:51] <Philip`> You lose the information that both insertions were simultaneous, but I'm not sure what you'd want that information for
# [22:52] <Dashiva> There's also Apple <ins>banana <em>pan </em></ins><em>pie</em>
# [22:53] * Joins: KevinMarks (n=KevinMar@nat/google/x-d49b5c69a3f52cc1)
# [22:54] <Philip`> That's bad because you can't recover the new piece of markup (Apple banana <em>etc) from the annotated-with-ins markup
# [22:55] <Philip`> You should be able to strip the <del> tags and delete the <ins> content to recover the first diffed document, and vice versa to recover the second
# [22:56] <Philip`> (or at least I'm asserting that you ought to be able to, because that seems like a useful property)
# [22:56] <Lachy> if you need to know the inserts were simultaneous for some reason, use <ins datetime="...">
# [22:57] <Philip`> Hixie: Has anyone already told you that http://www.whatwg.org/specs/web-apps/current-work/#attributes says "The cite DOM attribute must reflect the element's >cite content attribute." with a stray ">"?
# [22:58] <Philip`> Lachy: That doesn't really tell you they're simultaneous, since it can only have a precision of one second, and it's quite plausible that a heavily-edited document (e.g. the concatenation of all pages on Wikipedia) can have multiple edits per second
# [22:58] <Hixie> oh crap
# [22:58] <Hixie> did i break that recently
# [22:58] <Hixie> sigh
# [23:00] <Lachy> Hey Hixie, if you didn't read the earlier discussion in here about the entity table, just ignore my email about it. It was due to my failure to read the spec properly
# [23:00] <Hixie> already ignored :-D
# [23:00] <Lachy> :-)
# [23:02] <gsnedders> silly Lachy. Can't even read a specification how it says to be read :P
# [23:05] <Philip`> To be fair, if you didn't know how to read the specification then you wouldn't be able to read the part of the specification that says how to read it, so you can be excused
# [23:05] <gsnedders> Hixie: Can you fix that issue?
# [23:05] <gsnedders> (Within the spec, obviously)
# [23:06] <Lachy> gsnedders, if people actually read the spec and knew what they were talking about all the time, joining in on bikeshed discussions wouldn't be nearly as fun!
# [23:06] <Dashiva> gsnedders: We'll fix it the same way we fix content-type detection, maybe?
# [23:06] <gsnedders> Lachy: My. bikeshed. is. green. and. counts. in. micro-seconds.
# [23:08] <Lachy> LOL
# [23:08] * jwalden grumbles about midairs
# [23:09] <gsnedders> (see, I know what the thread that made bikeshedding famous was about :P)
# [23:10] <Dashiva> gsnedders: Mine doesn't count, it integrates
# [23:16] <Lachy> so regarding that datetime discussion, since they've still failed to describe valid use cases for BCE or Y10K+ dates in markup, it seems the only possibly valid argument for it is to allow DOMDateTime objects and datetime attributes able to express the same range of values
# [23:18] * Joins: roc (n=roc@121-72-179-147.dsl.telstraclear.net)
# [23:25] * Joins: qwert666_ (n=qwert666@acdg62.neoplus.adsl.tpnet.pl)
# [23:26] <Dashiva> Lachy: I'm wondering how they plan to get accurate dates, much less times, for anything that old
# [23:28] <Hixie> anything before the gregorian calendar starts is a non-starter anyway
# [23:29] <Lachy> Dashiva, all of history is recorded in google calendar. :-)
# [23:31] <Lachy> the universe was created in 1970. Anything before then is an epoch fail.
# [23:32] * Joins: othermaciej (n=mjs@17.203.15.181)
# [23:33] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [23:37] <Philip`> In Y10K we'll all live in space and time won't have a fixed meaning any more, so we'll have already solved all the time problems
# [23:38] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [23:43] * Quits: qwert666 (n=qwert666@acbg217.neoplus.adsl.tpnet.pl) (Connection timed out)
# [23:44] * Quits: KevinMarks (n=KevinMar@nat/google/x-d49b5c69a3f52cc1) ("The computer fell asleep")
# [23:45] * Quits: sverrej_ (n=sverrej@89.10.27.86) (Read error: 104 (Connection reset by peer))
# [23:49] <Dashiva> Imagine all the awesome compatability layers we'll get for supporting earth-based dates and times
# [23:51] * Quits: phsiao (n=shawn@nat/ibm/x-0234d479eec745e0)
# [23:52] * Joins: sverrej (n=sverrej@89.10.27.86)
# [23:53] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [23:54] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [23:54] <Lachy> Maybe we'll just have clocks that compensate for time dialation and maintain earth-time, no matter where we are or how fast we're going.
# [23:57] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
# [23:59] <Philip`> If you get put in a spaceship in suspended animation, and it's sent at 0.9c to a star a couple of light years away, what time would you say it was when you arrived?
# Session Close: Sat Apr 26 00:00:00 2008

The end :)