Monday, 2015-01-19

*** conan <conan!~conan@80.229.38.205> has joined #immutant00:11
*** DomKM <DomKM!uid23709@gateway/web/irccloud.com/x-xjeokvsviynqeslb> has joined #immutant01:01
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant01:30
*** je <je!~je@x1-6-c0-3f-0e-f8-01-dc.cpe.webspeed.dk> has quit IRC (Ping timeout: 276 seconds)01:53
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 256 seconds)02:06
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant02:55
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 264 seconds)03:12
*** kschrader <kschrader!uid41175@gateway/web/irccloud.com/x-duqkoxsgyutwbcnq> has quit IRC (Quit: Connection closed for inactivity)06:45
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant07:08
*** galderz <galderz!~galder@redhat/jboss/galderz> has joined #immutant07:14
*** galderz <galderz!~galder@redhat/jboss/galderz> has quit IRC (Remote host closed the connection)07:14
*** _kardan <_kardan!~daniel_ka@c-31-209-39-157.cust.bredband2.com> has joined #immutant07:26
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Remote host closed the connection)07:50
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant07:51
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Ping timeout: 245 seconds)07:55
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant08:23
*** je <je!~je@mail.natur-energi.dk> has joined #immutant08:29
*** qwerty_nor <qwerty_nor!~Thunderbi@5.248.107.224> has joined #immutant09:32
*** mgaare <mgaare!~quassel@75.127.15.55> has quit IRC (Ping timeout: 256 seconds)10:38
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 264 seconds)11:39
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant11:44
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant12:05
*** egli <egli!~user@alouette.sbs.ch> has joined #immutant12:39
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 265 seconds)12:52
*** _kardan <_kardan!~daniel_ka@c-31-209-39-157.cust.bredband2.com> has quit IRC (Ping timeout: 265 seconds)13:03
*** galderz <galderz!~galder@redhat/jboss/galderz> has joined #immutant13:10
*** tcrawley-away is now known as tcrawley13:11
*** je <je!~je@mail.natur-energi.dk> has quit IRC (Ping timeout: 245 seconds)13:41
*** lance|afk is now known as lanceball14:32
*** jcrossley3-away is now known as jcrossley315:22
jodaromornin15:23
tcrawleyjodaro: howdy!15:25
jodarohey, are you guys planning on being at Clojure West this year?15:33
jcrossley3jodaro: we think so, yeah15:33
jodarodeuce talk?15:37
jcrossley3hopefully. an unsession, at the minimum.15:40
jcrossley3jodaro: any particular deuce-related talk topic strike your fancy?15:40
jodarohmmm15:41
jodaromaybe just a full overview?15:41
jodarowith some live coding15:41
jodaroand a dancing bear and fire eater?15:41
jcrossley3we've done [most of] that before, but it was a while ago15:42
tcrawleyhow about a bear eater?15:42
jodaroyeah, could be a bear eater, and might as well light them both on fire15:42
jodaroI was thinking about submitting a talk15:44
jcrossley3cool, what kind?15:44
jodarobut I need to distill some of my ideas down a bit before I do15:44
jodarowell, probably some aspect of the stuff I've been doing15:44
jodarolots of event processing15:45
jodarobut everyone is doing that these days15:45
jodaroso id need a hook15:45
jodarolike how to process 1 billion events a day while eating a flaming bear15:46
jodarohow to do streaming event processing without a streaming event processing framework15:47
jodarohow to champion clojure in your organization without getting beaten up behind the gym after 4th period15:49
jodaromaybe i could give a meta talk about how to come up with talk ideas with catchy titles15:50
tcrawleyha15:50
jcrossley3i'd attend any one of those talks based on the title alone16:05
jodarosee?16:08
jodarolooks like the dates are free in the family calendar16:08
jodaroso i might try to go one way or another16:08
jcrossley3yay!16:08
jodaroi'll bring it up with el bossman today16:08
jodaroel bosshombre, i guess16:08
jodaroif i'm going with spanish16:09
pdurbinyou'd think a knitted castle would get you beaten up16:14
*** itruslove_ <itruslove_!~itruslove@ec2-107-20-95-59.compute-1.amazonaws.com> has quit IRC (Max SendQ exceeded)16:28
*** itruslove <itruslove!~itruslove@ec2-107-20-95-59.compute-1.amazonaws.com> has joined #immutant16:28
*** itruslove <itruslove!~itruslove@ec2-107-20-95-59.compute-1.amazonaws.com> has quit IRC (Max SendQ exceeded)16:29
*** itruslove <itruslove!~itruslove@ec2-107-20-95-59.compute-1.amazonaws.com> has joined #immutant16:29
*** itruslove <itruslove!~itruslove@ec2-107-20-95-59.compute-1.amazonaws.com> has quit IRC (Max SendQ exceeded)16:30
*** itruslove <itruslove!~itruslove@ec2-107-20-95-59.compute-1.amazonaws.com> has joined #immutant16:30
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant16:33
*** galderz <galderz!~galder@redhat/jboss/galderz> has quit IRC (Quit: Leaving)16:40
*** cap10morgan <cap10morgan!~cap10morg@2601:1:b200:1c6:59bb:ba18:d8f3:83b4> has joined #immutant16:55
jodaroi'm sure it would17:08
jodaroeveryone i grew up with would have handed out countless beatdowns for a knitted castle17:09
jodaroeven a lego castle, come to think of it17:09
jodaroonly a castle made of blood, sweat and tears would get you a pass17:09
jcrossley3gross17:10
pdurbinheh17:11
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 240 seconds)17:24
*** bbrowning <bbrowning!~bbrowning@redhat/jboss/bbrowning> has joined #immutant17:33
tcrawleyjcrossley3: howdy! I'm having issues getting path-info and context for websocket upgrades17:59
tcrawleythe handshakes only give you the requestURI17:59
tcrawleyI'm tempted to have the handshake impls of RingRequest's context and path-info either: 1) return nil, b) throw18:00
tcrawleythoughts?18:00
jcrossley3tcrawley: are we working today? :)18:01
tcrawleydo we work any day?18:02
jcrossley3lemme get the code in front of me18:02
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant18:02
jcrossley3tcrawley: what did we used to have?18:06
jcrossley3i guess not a HSR18:07
*** irsol <irsol!~irsol@unaffiliated/contempt> has quit IRC (Ping timeout: 264 seconds)18:07
tcrawleywe never had anything before the streaming changes, since you didn't have a ring request at upgrade time18:08
jcrossley3i guess throw if there's no reasonable way to get them18:10
jcrossley3they're not nil18:10
jcrossley3IllegalStateException maybe?18:10
tcrawleyyeah, that makes sense18:11
jcrossley3you could argue that all your no-ops should toss, too18:11
tcrawleyI was just thinking about that18:11
jcrossley3seems like some of them shouldn't be no-ops though, e.g. remote-addr, character-encoding18:13
jcrossley3maybe throw NotImplmentedYet("What do you expect us to do here?")18:13
jodaroheh18:14
tcrawleytrue, we should be able to get the character encoding, but maybe we should always return UTF-8? because any character encoding requested for ws will be ignored. UTF8 is the only valid option18:14
tcrawleyremote-address isn't a no-op under undertow, only servlets18:15
tcrawleybecause I can't figure out how to get it for the latter18:15
jodaroWeCantDoEverythingForYouException18:15
tcrawleyheh18:15
*** irsol <irsol!~irsol@unaffiliated/contempt> has joined #immutant18:16
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has quit IRC (Ping timeout: 244 seconds)18:18
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has joined #immutant18:18
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has quit IRC (Changing host)18:18
*** jcrossley3 <jcrossley3!~user@redhat/jboss/jc3> has joined #immutant18:18
jcrossley3dammit18:19
jcrossley3tcrawley: where did we leave off?18:19
jcrossley3https://gist.github.com/2cbe57a80e8b4810c30f18:19
tcrawleyhttps://gist.github.com/35fb0d98a03809aaba8718:20
jcrossley3hmm18:21
jcrossley3did we used to test for path-info?18:24
tcrawleywe don't yet test websocket upgrades for it18:24
jcrossley3we don't seem to test for :context and :path-info at all18:24
tcrawleyyeah, true18:24
jcrossley3returning the same value for both is wrong, regardless18:25
tcrawleydefinitely - what we do now is very wrong :)18:25
jcrossley3you could probably make the case that :context shouldn't be in the map for an upgrade18:27
jcrossley3which makes its presence in RingRequest dubious, maybe18:27
jcrossley3it pains me how much thought we put into :context when most folks just mount at the root18:28
tcrawleyI think :context belongs in the ring request, because how else could it be communicated?18:29
tcrawleyI think it should be part of the upgrade handshake as well, because the endpoint is attached to a servlet that is on a context18:30
tcrawleybut if we don't have the info, it's probably best to throw18:30
jcrossley3ring proper only puts :context in there when deployed to a servlet container. it's not a "standard" key.18:30
jcrossley3you'd think jsr 356 would be able to link an upgrade to a context18:31
jcrossley3it's a fucking jsr for chrissakes!18:31
tcrawleyindeed18:31
tcrawleywhat's the ring spec's stand on :path-info?18:31
jcrossley3same, i think18:32
jcrossley3lemme do some ganderin'18:32
jcrossley3path-info may be standard18:33
jcrossley3nope18:33
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 245 seconds)18:34
*** charliekilo <charliekilo!charliekil@2600:3c00::f03c:91ff:fe56:b738> has quit IRC (Ping timeout: 244 seconds)18:42
*** charliekilo_ <charliekilo_!charliekil@2600:3c00::f03c:91ff:fe56:b738> has joined #immutant18:43
jcrossley3tcrawley: http://stackoverflow.com/questions/21888425/accessing-servletcontext-and-httpsession-in-onmessage-of-a-jsr-356-serverendpo18:44
jbossbotTitle: java - Accessing ServletContext and HttpSession in @OnMessage of a JSR-356 @ServerEndpoint - Stack Overflow18:44
jcrossley3we already do something similar18:45
jcrossley3using user props, i mean18:46
tcrawleythat may work, we just need to find the analog for undertow18:47
jcrossley3well, undertow implements jsr 356 :)18:49
tcrawleysure, but we don't use 356 when using handlers18:50
jcrossley3right, but whatever you can do in 356 has to be possible in undertow, so the answer should be in the source for undertow's impl of 35618:51
jcrossley3tcrawley: want me to take a whack at impl'ing those guys, to free you up to do other junk?18:52
tcrawleysure!18:52
jcrossley3kk!18:52
jbossbotgit [immutant] push thedeuce 021c2d8.. Toby Crawley Confirm chunked stream actually chunks [IMMUTANT-521]18:52
jbossbotgit [immutant] push thedeuce f1146ce.. Toby Crawley docs/whitespace.18:52
jbossbotgit [immutant] push thedeuce URL: http://github.com/immutant/immutant/compare/7739e27...f1146ce18:52
jbossbotjira [IMMUTANT-521] Add API for async channels [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-52118:52
*** je <je!~je@x1-6-c0-3f-0e-f8-01-dc.cpe.webspeed.dk> has joined #immutant18:53
jodaroaww yeah, my useless comment forever immortalized in a gist18:53
jodaroglad i helped out18:53
jcrossley3tcrawley: would it be better to indicate that reason passed to on-close is a map?18:54
tcrawley:)18:54
tcrawleyin the docs for as-channel? yes, definitely18:54
tcrawleyI'll work on those now18:54
jcrossley3it'd be nice to use standard codes for the streaming reasons, but i can't decide if that makes sense18:55
jcrossley3because wtf does 1000 mean?18:55
tcrawleyand that's the only code you'll ever see for a stream18:56
tcrawleyso maybe streams don't get close reasons at all18:56
jcrossley3surely they might fail?18:58
projectodd-ciProject immutant2-incremental build #432: FAILURE in 5 min 13 sec: https://projectodd.ci.cloudbees.com/job/immutant2-incremental/432/18:58
projectodd-ci* Toby Crawley: Confirm chunked stream actually chunks [IMMUTANT-521]18:58
jbossbotjira [IMMUTANT-521] Add API for async channels [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-52118:58
projectodd-ci* Toby Crawley: docs/whitespace.18:58
jcrossley3foiled again by whitespace18:59
tcrawleyhmm, that builds locally. I think I introduced a racist bug19:00
tcrawleythe stream failure that we handle is "broken pipe", which usually means the client has gone away, so we treat that as a normal closure19:02
jcrossley3tcrawley: so is there no valid reason for someone to register an on-close for http streaming?19:03
tcrawleyyou would register if you want to know when the stream closed19:04
tcrawleyto remove it from an atom of open connections, mayhap19:04
tcrawleysente does that19:04
tcrawleyyou know if you close it, but if the client closes it, you want to know that as well19:04
jcrossley3but you care fuckall for the reason?19:05
tcrawleymaybe you do care what the reason is, but what is the set of possible reasons?19:06
tcrawleySERVER_SIDE_CLOSE, CLIENT_GONE19:06
tcrawleythat's about it19:06
tcrawleyneither of which are modeled by the ws codes19:07
jcrossley3maybe http://tools.ietf.org/html/rfc6455#section-7.419:07
jbossbotTitle: RFC 6455 - The WebSocket Protocol19:07
tcrawley1000 means server *or* client closed19:07
jcrossley3does the http streaming rfc mention close reasons?19:07
tcrawley1001 kinda matches broken pipe19:08
tcrawleyprobably not, since it's just an http connection (part of the http 1.1 spec)19:09
tcrawleyjcrossley3: http-kit translates all codes to keywords: https://github.com/http-kit/http-kit/blob/master/src/org/httpkit/server.clj#L6919:15
tcrawleymaybe we should do something similar. because numeric codes aren't useful for ws either, unless you know the proto well19:18
jcrossley3hmm19:19
jcrossley3i've noticed that reason phrases differ among clients19:20
jcrossley3might suck to lose them19:20
jcrossley3but i agree keywords are more helpful than numbers19:21
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant19:41
*** cap10morgan <cap10morgan!~cap10morg@2601:1:b200:1c6:59bb:ba18:d8f3:83b4> has quit IRC (Quit: Computer has gone to sleep.)19:41
*** jcrossley3 is now known as jcrossley3-away19:49
*** qwerty_nor <qwerty_nor!~Thunderbi@5.248.107.224> has quit IRC (Ping timeout: 264 seconds)20:04
*** tcrawley is now known as tcrawley-away20:25
*** tcrawley-away is now known as tcrawley20:27
*** cap10morgan <cap10morgan!~cap10morg@184-96-185-7.hlrn.qwest.net> has joined #immutant20:30
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Remote host closed the connection)20:36
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant20:37
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has quit IRC ()20:40
*** bobmcw <bobmcw!~bobmcw@184.0.113.187> has joined #immutant20:41
*** bobmcw <bobmcw!~bobmcw@184.0.113.187> has quit IRC (Changing host)20:41
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has joined #immutant20:41
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Ping timeout: 255 seconds)20:41
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has quit IRC (Client Quit)20:43
*** bobmcw <bobmcw!~bobmcw@184.0.113.187> has joined #immutant20:43
*** bobmcw <bobmcw!~bobmcw@184.0.113.187> has quit IRC (Changing host)20:43
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has joined #immutant20:43
*** jcrossley3-away is now known as jcrossley321:14
*** tcrawley is now known as tcrawley-away21:38
*** cap10morgan_ <cap10morgan_!~cap10morg@172.56.12.8> has joined #immutant21:39
*** cap10morgan <cap10morgan!~cap10morg@184-96-185-7.hlrn.qwest.net> has quit IRC (Ping timeout: 245 seconds)21:42
*** cap10morgan__ <cap10morgan__!~cap10morg@184-96-185-7.hlrn.qwest.net> has joined #immutant21:42
*** tcrawley-away is now known as tcrawley21:43
*** cap10morgan_ <cap10morgan_!~cap10morg@172.56.12.8> has quit IRC (Ping timeout: 240 seconds)21:46
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 264 seconds)21:54
tcrawleyjcrossley3: how do you feel about https://gist.github.com/95d9f38b6960bdd2c433?22:04
jcrossley3tcrawley: the terms "code" and "reason" have specific meaning wrt websockets. hijacking reason for something else could be confusing.22:09
tcrawleyyeah, but I couldn't come up with anything better22:10
tcrawleythe meaning of :code remains the same though22:10
jcrossley3if i've used any other websocket library, except http-kit apparently :), i'll be expecting reason to be a string22:11
jcrossley3and now you're introducing a third group of reasons in addition to ws and hk?22:12
tcrawleyand you have to look at a numeric code to cond on the close?22:12
tcrawleyI'm giving a simplification of both22:12
jcrossley3are you?22:12
jcrossley3simplification usually involves less, not more22:13
tcrawleyI'm collapsing 12 ws codes in to 5, because 99% of the time, you don't care about the differences22:13
tcrawleyand 7 ws reasons to 522:13
tcrawleythat seems like less to me22:14
jcrossley312 + 7 + 522:14
jcrossley3you can't help that 12 and 7 already exist. you can do something about 5, though. :)22:14
tcrawleyonly 7 + 5 if you are using both immutant and http-kit22:15
tcrawleywhat would you propose? 12 keywords, or the same 7 from http-kit?22:15
jcrossley3personally, i don't like that hk added its 7.22:16
jcrossley3i guess 1222:16
tcrawleyfor h-k, 2 are used for http channels, the other five for ws22:16
jcrossley3i do like the keywords22:16
jcrossley3i'd just like to follow the standard, i think22:16
jcrossley3i'm not totally on board with all of hk's design decisions22:17
tcrawleyI agree, which is why I went with something simpler than what they have :)22:17
tcrawleyone problem is that the ws codes don't apply directly to http channels, so we'd need *more* than 1222:17
jcrossley3would (fn [ch reason {:keys [code reason-phrase]}] ...) be terrible?22:18
jcrossley3i kinda hate it22:18
tcrawleywith no keyword?22:18
jcrossley3reason would be the keyword22:18
tcrawleyah, I missed it22:19
tcrawleyI considered that22:19
jcrossley3there'd be a 3rd arg22:19
jcrossley3i'm ambivalent about conflating streaming and websockets22:19
tcrawleybut figured if I cared about why on-close was called, I wouldn't mind destructuring or acessing the map22:20
jcrossley3in the large, i like it. but there will be cruft like this at the edges.22:20
tcrawleyyes, the question is, does the cruft outweigh the benefit?22:21
*** cap10morgan__ <cap10morgan__!~cap10morg@184-96-185-7.hlrn.qwest.net> has quit IRC (Quit: Computer has gone to sleep.)22:21
jcrossley3how about (fn [ch {:keys [event code reason]}] ...)22:21
tcrawleyI like event, that's good22:22
jcrossley3tcrawley: i don't love it.22:23
jcrossley3if i'm dealing with websockets, i like code and reason22:24
jcrossley3i equate a 1000 in websockets to a {:status 200} ring response22:24
jcrossley3that is, if you're dealing with http, you're expected to know some codes22:25
tcrawleyand that would be available to you here with {:keys [code reason]}22:25
tcrawleyyou can ignore event22:25
jcrossley3right, exactly22:25
jcrossley3i'm talking myself out of event entirely22:25
jcrossley3i was briefly lulled22:25
jcrossley3lured?22:25
jcrossley3tricked?22:26
tcrawleybut event allows you to switch on event types without having to match all the codes22:26
jcrossley3would that be a good thing to do for HTTP status codes, too?22:26
jcrossley3i don't think so22:26
tcrawleyyou have that with the first digit of http codes22:26
tcrawleyand if I'm only doing streaming, why would I care about ws codes?22:27
jcrossley3sometimes i feel like you can see the point fly right by you, but you keep your eyes straight ahead, fixed on me in a cold dead starre22:27
tcrawleymaybe you need to be more explicit with the point then, if you think I missed it22:28
jcrossley3i'm not sure what the right answer is. i concur that a streaming user wouldn't care about ws codes.22:29
jcrossley3but i'm also not sure that user would care about the 5 new ones either22:29
tcrawleywould you rather do (if (= event :error)) or (if (or (<= 1002 code 1003) (<= 1007 code 1011))22:30
jcrossley3tcrawley: the spec is what it is22:30
*** bbrowning is now known as bbrowning_away22:30
tcrawleytrue, most of the time you would not care what the reason is at all22:31
tcrawleythe spec is what what is?22:31
tcrawleythe point?22:31
jcrossley3it doesn't matter what i'd prefer, because if we're writing a websocket library, we should follow the websocket spec, i think.22:31
tcrawleywe provide the spec codes and reasons, along with the sugar of classifying them in to groups22:32
jcrossley3i'm not sure adding :event to the map adds clarity, but i trust your judgment if you do.22:32
tcrawleyI'm just concerned about streaming.22:33
jcrossley3in what way?22:33
tcrawleyw/o streaming, I might just give code and reason22:33
tcrawleyw/streaming, what's the code for normal closure?22:33
tcrawley200?22:33
tcrawleywhat's the code for the client going away?22:34
jcrossley3is it reasonable to trigger on-error for that instead?22:34
jcrossley3if so, maybe return an empty map on a normal close?22:34
jcrossley3i need to go next door again. i'll give it more thought.22:35
tcrawleyI considered on-error, but it's a fairly normal thing for the browser window to close, so I considered it a close instead22:35
tcrawleymaybe streams always give {} (like you suggested above). and ws provide just code and reason22:41
*** lanceball is now known as lance|afk22:42
tcrawleyI've considered exposing on-complete and on-error callbacks to send!, which would allow for backpressure when using a websocket22:48
tcrawleymaybe when the client disappears, we call on-close, *and* we call the on-error for the send22:48
tcrawleybecause we can only detect that the client is gone by catching an IOE on send22:49
tcrawleythen, if the user needs to care about client disappearance, they can (re-find #"Broken pipe") in on-error22:49
tcrawleyit does complicate the api though22:50
tcrawley2-4 callbacks to as-channel, 2 to send!22:50
tcrawleybut we need those latter 2 if we want backpressure22:51
*** tcrawley is now known as tcrawley-away23:05
*** tcrawley-away is now known as tcrawley23:17
jcrossley3tcrawley: i like that better, though i'm unclear how those two callbacks enable backpressure23:18
tcrawleywell, really the on-complete does for a ws23:18
jcrossley3is that just the sender responding to an on-error by ceasing to send?23:18
tcrawleyw/o it, you have no way to know that you are overwhelming the network, since send! is async for ws23:18
tcrawleywith on-complete, you don't call send! again until the last send! completes23:19
jcrossley3but you'd still have to respond to the callbacks somehow to get backpressure23:19
jcrossley3ah, right. gotcha.23:19
tcrawleypassing an exception to send!'s on-error when the client goes away does require the user to have more knowledge of the mechanics, but maybe that's not a bad thing (same as requiring code/reason knowledge if you care about ws closure)23:21
jcrossley3mayhap23:23
tcrawleycan you wang for a couple of minutes?23:24
*** cap10morgan__ <cap10morgan__!~cap10morg@c-50-134-198-253.hsd1.co.comcast.net> has joined #immutant23:24
tcrawleyjcrossley3: ^23:27
jcrossley3sure23:28
*** tcrawley is now known as tcrawley-away23:51

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!