<mcarter> Hixie, thanks for your quick solution with the lastEventId
* roc has quit ()
* eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net) has joined #whatwg
<Hixie> mcarter: my pleasure, though i should emphasise that you're actually just lucky :-)
<Hixie> mcarter: i just happened to be going through folders that only had 1 e-mail
<mcarter> Hixie, how did my email end up being the only one in a folder?
<Hixie> mcarter: there was no other outstanding feedback for event-source
<mcarter> so I've got a number of suggestions I'm working on for tcp connection
<mcarter> any advice on how to make those go to just the right folder? ;-)
<othermaciej> if I were offering bets on features in the final spec, I would give tcp connection slim odds of making the cut
<mcarter> othermaciej, I think you're spot on giving its current state and lack of interest
<mcarter> othermaciej, but I've succcessfully implemented it in javascript, on top of sse implemented in javascript, and I have a number of suggestions that might help
<othermaciej> mcarter: I don't see how that is possible
<mcarter> othermaciej, and even if it doesn't make it into browsers right away, having a spec to base the javascript implementation(s) on is very nice
<mcarter> othermaciej, well, obviously not the protocol
<othermaciej> since the whole point of the feature is that it makes a raw TCP connection
<othermaciej> and does two-way messaging over the single established socket
* eseidel has quit ()
<mcarter> i'm not saying i've perfectly emulated a native implementation
<mcarter> rather that if you make your sse server open the actual socket, and allow the sse server to receive upstream over xhr requests and have some way of identifiying messages to a particular connection
<othermaciej> I do think a full duplex communication feature would be great
<mcarter> then you end up with a nearly identical api to tcpconnection
<othermaciej> but I a not a fan of the specific design of TCPConnection
<mcarter> is it the api provided by tcpconnection, or the underlying protocol?
* jwalden has quit (Remote closed the connection)
<othermaciej> by TCPConnection
<othermaciej> but I don't think the API is the big value add
* MacDome (n=eric@c-24-130-11-246.hsd1.ca.comcast.net) has joined #whatwg
<othermaciej> if you want to emulate full duplex messaging and don't care how many connections you use, you can just use XHR
<MacDome> another CD came! yay!
<mcarter> othermaciej, so what is it that you think is wrong with TCP Connection?
* othermaciej has quit ()
* MacDome wonders if mcarter is talking about the SVG 1.2 Connection object...
<MacDome> or something entirely different
<Hixie> mcarter: just sending feedback to whatwg@whatwg.org is enough
<mcarter> MacDome, http://www.w3.org/html/wg/html5/#tcp-connections
<Hixie> mcarter: it'll be put in the right folder when i read it :-)
<mcarter> Hixie, heh, the way othermaciej frames it, the right folder will be the trash
<Hixie> MacDome: http://www.whatwg.org/specs/web-apps/current-work/#network
<Hixie> i guarentee to reply to all actionable feedback sent to whatwg@whatwg.org
<MacDome> hum...
<MacDome> sounds scary
* MacDome wonders if Hixie saw mjs's feedback on SVG 1.2 Connection
<Hixie> http://www.whatwg.org/issues/data.html tracks my progress on that front :-)
<Hixie> MacDome: SVG 1.2 Connection was a disaster compared to this
<Hixie> MacDome: though maciej things this is a disaster too, so... :-)
<Hixie> thknks
<Hixie> thinks
<mcarter> Hixie, the first two proposals are api, and I'll send them when i finish. I think there should be an explicit connect() function, and one more ready state (before connect() is called is a new readystate)
<MacDome> Hixie: well, I'm just glad you're the one specing this
<MacDome> Hixie: but in general I would trust mjs over you in this area (nothing personal)
<mcarter> Hixie, also, I have a pretty reasonable suggestion about the protocol, using HTTP upgrades instead of a custom protocol. I'll send that when i get it ready as well
<mcarter> just giving you a bit of heads up
* MacDome would have to think about what sort of evil things are possible with Connection
<Hixie> MacDome: his feedback is in the pile somewhere, and i have no intention of ignoring it :-)
<MacDome> Hixie: again, why I'm glad you're specing this :)
<Hixie> mcarter: cool, thanks
<MacDome> his SVG 1.2 Connection feedback was ignored :(
<Hixie> shocking
<Hixie> MacDome: iirc my biggest problem with mjs' feedback was that he wants it to use HTTP instead, and that seems like a giant amount of work for the server side
<MacDome> (for those who don't read Hixie, he's being facetious)
<MacDome> Hixie: http is definitely a smaller problem space
<MacDome> Hixie: and is stateless
<Lachy> Hixie, these statement's seem redundant in the spec: "If a dl element contains only dt elements, then it consists of one group with names but no values."
<Lachy> "If a dl element contains only dd elements, then it consists of one group with values but no names." - Since those cases are covered by the 2 subsequent conditions
<MacDome> Hixie: but I'd have to give it some thought
<Hixie> Lachy: hm, true, i guess
* MacDome just now realizes that he's in #whatwg instead of #webkit
* MacDome goes back to friendlier waters :)
<mcarter> Hixie, if you use http you could tunnel through proxies a lot easier AND stop worrying about connections to the SMTP servers without adding yet another simple protocol to the world
<Hixie> aww, MacDome, don't go away :-)
<MacDome> Hixie: I'm never far. and you have plenty of ways to reach me ;)
<Hixie> mcarter: but if you use http the server side goes from a ten line perl script to a 3000-line perl script
<Hixie> mcarter: and you'll end up with nobody ever actually writing a compliant server
<MacDome> Hixie: or you just put your stuff behind an http frontend
<Hixie> MacDome: how?
<MacDome> Hixie: how not?
<mcarter> Hixie, how about a protocol that is a strict subset of http such that you only need to know how to read a couple of headers and send back an error or ok header?
<Hixie> MacDome: the problem we're trying to solve is real-time duplex communication
<Hixie> mcarter: then it's not HTTP
<Hixie> mcarter: at which point, why bother with the pretense
<MacDome> Hixie: which is possible with two HTTP connections, no?
<mcarter> Hixie, the pretense is mostly there so that it starts as an http request and can use the browser's proxy settings to establish the connection
<mcarter> Hixie, i think http is a bad solution for a tcp connection, but practically speaking we *really* want to get through locked down systems
<Hixie> MacDome: the web browser can't receive connections, it's behind NAT typically
<Hixie> mcarter: can't you tunnel anything through 443?
<MacDome> Hixie: I meant that the browser could open up two conenctions, one which it sends on, the other which it receives on
<MacDome> i mean, I guess you should be able to do it with one
<Hixie> MacDome: if you layer that on top of an http frontend, you end up with two processes, where you really just want one
<Hixie> MacDome: onthe server
<mcarter> Hixie, the main issue isn't really the port number so much as the forward proxy sitting between you and the outside world (where "you" is some poor student or employee.)
* MacDome goes back to fixing CSS3 bugs
<Hixie> mcarter: do https: connections go through said proxy?
<mcarter> Hixie, yeah
* MacDome claims ignorance for all networking issues
<Hixie> mcarter: i thought the way https worked was that all data was just forwarded through untouched
<Hixie> mcarter: how does https work?
<mcarter> Hixie, they start with a CONNECT, and then after that all data is untouched
<Hixie> oh
<Hixie> interesting
<Hixie> didn't know that
<Hixie> well we probably want to do something similar then, i agree
<mcarter> but we can't just open a connection to an arbitrary external address
<mcarter> we actually have to open the connection to the forward proxy, then use a CONNECT to specify the external address
* jruderman has quit ()
<Hixie> sure
<Hixie> that's ok
<Hixie> can't we just define that that is how this protocol is handled when there's a proxy?
<Hixie> i.e. that you proxy it over whatever HTTP proxy is set up?
<mcarter> so as long as the browser agrees to expose the proxy information to their TCPConnection implementation, and use connect, then it could work out
<mcarter> exactly
<Hixie> makes sense to me
<mcarter> I'll put together a proposal that outlines the problem and that solution over the next couple of days and send it in
<Hixie> that would be awesome
<Hixie> thanks!
* jruderman (n=jruderma@guest-226.mountainview.mozilla.com) has joined #whatwg
<Hixie> basically my main requirements are that: (1) there be the ability for one process to have a full-duplex communication channel to the script running in the web page
<Hixie> (2) the server-side be implementable in a fully conformant way in just a few lines of perl without support libraries
<Hixie> (3) that it be safe from abuse (e.g. can't connect to smtp servers)
<Hixie> (4) that it work from within fascist firewalls
<mcarter> yeah, those requirements are spot on
<mcarter> (2) is a bit tricky when you start requiring HTTP or even a subset of it
<Hixie> right
<mcarter> i still think there are a couple of other reasons why http might be a good idea, but i need to think about it more. I too want this to be as simple as possible so long as it works
<Hixie> oh i agree that there are a number of compelling reasons to base this on http
<Hixie> just not reasons that i would classify as requirements :-)
<mcarter> heh
<mcarter> so the spec seemed to indicate no resolution on the same-source origin policies for tcpconnection
<mcarter> i think there was some comment about "maybe allowing cross-domain" connections or something
<Hixie> yeah
<mcarter> even for cross-subdomain stuff you have the afore-mentioned dns rebinding attack
<Hixie> i plan to cut out all the crap about local network connections and peer to peer stuff and broadcast stuff
<Hixie> and to make it cross-domain
<mcarter> which a Host header you can solve dns rebinding
<Hixie> yeah
<Hixie> i was about to say i think we should include an equivalent to the Host header
<Hixie> that would allow for shared hosting, too
<mcarter> right
<Hixie> in some future where there's some cool thing that everyone is doing using this
<mcarter> also, i'm not convinced it makes sense to create a protocol that can't identify what version of the protocol it is
<Hixie> yeah, people always think you should version protocols
<Hixie> it's ok
<Hixie> you grow out of it :-)
<mcarter> haha
<mcarter> at any rate, I really do have a pretty neat implementation of the TCPConnection api, but over sse and xhr
<mcarter> it makes for a nice dream, of some day having that be native =)
<Hixie> you don't need to version the protocol if it's designed in a way that it extends with well-defined behaviour in down-level clients
<Hixie> :-)
<Hixie> (e.g. css and html aren't versioned)
<Hixie> (html4 and before look like they're versioned, but they're not really)
<mcarter> I'm not convinced
<Hixie> versioning doesn't work when you have multiple implementations and an evolving spec
<mcarter> well, thats a good point I suppose
<mcarter> Thats what headers are for
<mcarter> I don't actually care too much if we use http or not, i just need to put all my thoughts down somewhere and come up with coherent comparison of advantages and disadvantages
<mcarter> and send it to the list
<Hixie> that would be great
<mcarter> I am sort of hoping that a cross-browser implementation of the api (both server-side and client side, via javascript hackery and a server-side xhr/sse->socket proxy) can help push the standard forward in the face of browser non-adoption
<mcarter> so with the orbited project (open source comet server in python www.orbited.org) we are getting close to that, and even if TCPConnection it drops out of the specification, its a nice abstraction for server-side and javascript-side developers
<mcarter> I'll keep you posted
<inimino> that would be excellent
<inimino> (TCPConnection with a back-compat JS library)
<mcarter> inimino, yeah, and we've already got all the proof of concept work done on it. So you can expect it in the near future
<Hixie> please do (keep me posted). this sounds cool.
<Hixie> man i hope the forms stuff gets resolved soon
<Hixie> i have so many WF2 and WF3 feedback e-mails