The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2015-11-29

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:14 pink_mist joined #mojo
00:21 sue joined #mojo
00:45 woz joined #mojo
00:59 jontaylor joined #mojo
01:09 woz joined #mojo
01:20 vanHoesel joined #mojo
01:31 cpan_mojo AI-MicroStructure-0.19 by SANTEX https://metacpan.org/release/SANTEX/AI-MicroStructure-0.19
01:31 woz joined #mojo
01:35 thowe joined #mojo
01:48 woz joined #mojo
01:58 asarch joined #mojo
02:01 jontaylor joined #mojo
02:11 Grinnz another "wat." dist from santex
03:12 noganex joined #mojo
03:22 Zoffix joined #mojo
03:25 jnbek joined #mojo
03:48 woz joined #mojo
04:35 jnbek joined #mojo
04:37 voldemortensen joined #mojo
04:45 sivoais joined #mojo
04:50 sivoais joined #mojo
05:18 woz joined #mojo
06:06 cfedde joined #mojo
06:49 woz joined #mojo
07:23 kaare joined #mojo
07:53 dod joined #mojo
07:58 dod joined #mojo
08:03 trone joined #mojo
08:04 Vandal joined #mojo
08:27 woz joined #mojo
08:41 n16gel joined #mojo
09:02 meshl joined #mojo
09:02 stephen joined #mojo
09:14 woz joined #mojo
09:26 kyshtynbai joined #mojo
09:30 woz joined #mojo
09:42 sue joined #mojo
09:46 woz joined #mojo
10:07 sh4 joined #mojo
10:12 vanHoesel joined #mojo
10:16 n16gel joined #mojo
10:18 woz joined #mojo
10:29 woz joined #mojo
10:43 vanHoesel joined #mojo
11:02 geheimnis` joined #mojo
11:05 kaare joined #mojo
11:19 woz joined #mojo
12:20 woz joined #mojo
12:24 marcusr tempire: https://hackaday.io/project/7860-nyan-board # time to get into electronics?
12:48 woz joined #mojo
12:49 vanHoesel joined #mojo
12:49 Zoffix left #mojo
13:10 woz joined #mojo
13:25 asarch joined #mojo
13:30 woz joined #mojo
14:06 meshl joined #mojo
14:11 sue joined #mojo
14:22 meshl joined #mojo
14:32 woz joined #mojo
14:34 ajr_ joined #mojo
14:43 asarch Wow! You don't MongoDB after all: SELECT to_json(c.*) FROM student c WHERE id = 1;
14:43 asarch ...in a PostgreSQL cluster :-)
14:47 jberger or just store the data as jsonb
14:48 woz joined #mojo
14:57 ashimema jsonb++
15:03 good_news_everyon joined #mojo
15:03 good_news_everyon [mojo] jberger created jberger_channel (+1 new commit): http://git.io/vBDW6
15:03 good_news_everyon mojo/jberger_channel 766c209 Joel Berger: moved http server_read and server_write to Channel implementation
15:03 good_news_everyon left #mojo
15:37 asarch Wow! MongoDB is dead \o/
15:39 sri i for one welcome our new postgresql overlords
15:40 sri where's postgres 9.5 anyway?
15:42 * jberger taps fingers
15:53 sue joined #mojo
16:04 marty_ joined #mojo
16:25 marty joined #mojo
16:27 woz joined #mojo
16:30 jnbek joined #mojo
16:52 sri jberger: i wonder how http/2 fits into your approach
16:52 jberger I really don't know
16:52 sri thing is, http/2 is stateful
16:53 sri so, the channel would have to be something persistent
16:53 sri and there might be two or more transaction tied to a channel
16:53 sri +s
16:54 good_news_everyon joined #mojo
16:54 good_news_everyon [mojo] jberger pushed 1 new commit to jberger_channel: http://git.io/vBDQQ
16:54 good_news_everyon mojo/jberger_channel 4f8ff71 Joel Berger: move client_ methods too
16:54 good_news_everyon left #mojo
16:57 sri the server would have to create and store the channel with the connection
16:58 sri but the channel would have to notify the server when a new transaction starts
17:20 woz joined #mojo
17:28 sri i guess for http/2 it would make more sense if the channel was stateless and tied to the connection
17:29 sri this could work for http/1 too
17:29 sri hmm
17:34 jberger I can't figure out why the tests for t/mojo/daemon.t stall
17:34 jberger I must be missing something
17:37 punter joined #mojo
17:45 cpan_mojo Clustericious-1.06 by PLICEASE https://metacpan.org/release/PLICEASE/Clustericious-1.06
17:59 marty joined #mojo
18:01 bpmedley joined #mojo
18:11 good_news_everyon joined #mojo
18:11 good_news_everyon [mojo] jberger pushed 1 new commit to jberger_channel: http://git.io/vByL5
18:11 good_news_everyon mojo/jberger_channel 04cd573 Joel Berger: be sure to use the $server class
18:11 good_news_everyon left #mojo
18:11 jberger that feeling when you know you found the bug ... and then it doesn't fix the problem :'(
18:15 woz joined #mojo
18:34 ajr_ joined #mojo
19:24 good_news_everyon joined #mojo
19:24 good_news_everyon [mojo] jberger pushed 1 new commit to jberger_channel: http://git.io/vByBT
19:24 good_news_everyon mojo/jberger_channel c4b742b Joel Berger: move _close and resume methods
19:24 good_news_everyon left #mojo
19:28 sri hmm, a channel has a transaction and the transaction has a channel
19:28 sri that's not very elegant
19:33 sri btw. everyone here can chime in, these are important design decisions
19:33 sri the more eyeballs the better
20:03 woz joined #mojo
20:06 jzawodn joined #mojo
20:19 jberger The tests still hang
20:20 jberger I also think it might be possible to break that cyclic dependency without the backcompat code
20:20 jberger But honestly for now the backcompat is easier since I can lean on the existing tests
20:45 good_news_everyon joined #mojo
20:45 good_news_everyon [mojo] jberger pushed 1 new commit to jberger_channel: http://git.io/vByM0
20:45 good_news_everyon mojo/jberger_channel ec77517 Joel Berger: typo
20:45 good_news_everyon left #mojo
20:48 sri jberger: ok, makes sense
21:05 woz joined #mojo
21:10 Zoffix joined #mojo
21:11 Zoffix left #mojo
21:14 good_news_everyon joined #mojo
21:14 good_news_everyon [mojo] jberger pushed 1 new commit to jberger_channel: http://git.io/vByQz
21:14 good_news_everyon mojo/jberger_channel 4468af4 Joel Berger: missed a method delegation
21:14 good_news_everyon left #mojo
21:14 * jberger keeps finding bugs, keeps not fixing the hang
21:15 jberger I might end up redoing the who thing in an order which keeps the test passing the whole time
21:15 jberger whole
21:17 sri well, the test results point at big bugs https://travis-ci.org/kraih/mojo/jobs/93825105
21:18 sri "Can't call method "resume" on an undefined value at /home/travis/build/kraih/mojo/blib/lib/Mojo/Transaction.pm line 47"
21:19 sri "Can't use string ("Mojo::Transaction") as a HASH ref while "strict refs" in use at /home/travis/build/kraih/mojo/blib/lib/Mojo/Base.pm line 59"
21:19 sri stuff is being called on a class instead of an object
21:27 n16gel joined #mojo
21:27 voldemortensen joined #mojo
21:27 jberger the resume one I understand
21:28 jberger sri: this bit scares me: https://github.com/kraih/mojo/blob/master/lib/Mojo/UserAgent.pm#L337-L340
21:29 jberger oh, maybe that's ok
21:34 jberger ah, I found some of it
21:38 jberger and the HASH ref things are invalid tests
21:38 jberger testing the abstract methods by calling the method on the class
21:43 jberger so most of my problem is this
21:44 jberger I tried to inject compatibility code into the server_* and client_* methods which would disambiguate which type of channel to build and continue to use later
21:44 jberger but if one of the truly ambiguous methods is called first, like resume, things go to hell
21:44 jberger or even is_writing
21:45 jberger so my mechanism of back-compat isn't good enough
21:56 sue joined #mojo
22:05 jberger sri: for the websocket channels, do the other server/client methods like server_handshake etc go into the channel or stay in the transaction?
22:07 sri channel i think
22:08 sri or even split up
22:08 sri client_challenge could be renamed without prefix maybe
22:09 jberger (I'm going to commit the changes which fix a lot of the tests and expose the other problems)
22:09 sri think i would try to move as much as possible into the channels
22:10 meshl joined #mojo
22:10 sri client_handshake is a bit of an annoying case because it's called from Mojo::UserAgent::Transactor
22:11 sri oh my, ->server_close is actually called from Mojo::Server::PSGI/CGI too :O
22:12 sri channels make no sense at all there
22:13 sri perhaps Mojo::Transaction needs a new generic "close" method
22:25 woz joined #mojo
22:30 woz joined #mojo
22:33 woz joined #mojo
22:36 jberger that could probably work
22:38 good_news_everyon joined #mojo
22:38 good_news_everyon [mojo] jberger pushed 1 new commit to jberger_channel: http://git.io/vBSUz
22:38 good_news_everyon mojo/jberger_channel d083a8c Joel Berger: disambiguate server/client more
22:38 good_news_everyon left #mojo
22:39 woz joined #mojo
22:39 jberger my encapsulation is still bad :p
22:39 jberger but that should fix a lot of the non-websocket tests
22:42 jnbek joined #mojo
22:42 sivoais joined #mojo
22:43 jberger what does the Mojo::Transaction::WebSocket::is_writing method represent?
22:44 jberger the underlying transaction or the websocket itself
22:44 jberger underlying http request
22:45 sri websocket
22:46 jberger how does it do that?
22:46 sri grep WebSocket.pm for "state"
22:48 jberger argh, I've been reading this for too long, I grepped for writing
22:50 woz joined #mojo
22:55 jberger I keep going back and forth on whether Mojo::Channel::WebSocket::* should be subclasses of Mojo::Channel::HTTP::*
22:55 jberger it is really starting to feel like roles might be nice
22:55 jberger but thats out of scope
22:57 sri tight coupling there could turn into a huge mistake
22:57 PryMar56 joined #mojo
22:57 jberger so copying > inheriting
22:57 sri at some point there will be an http/2 handshake for websockets too
22:58 sri it might even end up being alpn
23:12 jberger for example client_close
23:12 jberger the polymorphism is strong with that one
23:14 jberger client_close is implemented in Mojo::Transaction but calls $self->server_close, which is implemented per-subclass
23:22 sri it doesn't really do much though, besides setting the state and emitting an event
23:23 sri doing that twice in the http and websocket base class wouldn't hurt much at all
23:23 sri i think the frame building/parsing stuff should also be moved into the channel
23:24 sri for websockets
23:24 jberger really?
23:24 sri absolutely
23:24 jberger that's analogous to the Message:: classes doing message parsing and generation
23:24 sri that's what the channel is all about
23:24 woz joined #mojo
23:24 sri no it's not
23:24 * jberger ponders
23:25 sri Mojo::Channel::HTTP glues the actual http messages together
23:25 jberger but the websocket frames are actually about transport
23:25 sri stringifying headers is only in Mojo::Headers because it's convenient
23:25 jberger closer to the tcp layer that the messages move over
23:25 sri not because it makes sense protocol abstraction wise
23:26 sri for http/2 it will be the same as for websockets
23:26 jberger there's not going to be a whole lot left in Transaction::WebSocket after that
23:26 sri that's good
23:27 sri like i said, transactions should be dumb containers
23:28 sri in fact, there might even be a websocket over http/2 spec at some point
23:28 sri that should be doable with the channel api :)
23:28 sue joined #mojo
23:29 jberger so the frame stuff goes into Mojo::Channel::WebSocket though right, not into the Server/Client subclasses?
23:29 sri the idea was to actually reuse http/2 frames to tunnel websocket frames through
23:29 sri right
23:29 jberger I really don't know enough about http/2 to guide design :s
23:30 sri it's really not that complicated, you don't need to know too many details
23:31 sri just that it's a stateful binary protocol, where requests and responses can be fragmented
23:31 sri stateful because you need to keep a compression context around, where you pipe headers through
23:31 sri that compression context changes with every new request/response
23:32 sri fragmented because it uses many different frame types, headers and body are always two separate frames
23:32 jberger that's interesting
23:32 sri often both are split up into multiple smaller frames
23:32 jberger makes the parser easier
23:33 jberger though you have to be careful abuot the statefullness
23:33 sri each frame is tied to a stream id, which is basically a session
23:33 jberger not a session like what I think of as a session
23:33 sri you can make many sessions on the same http/2 connection, to multiplex
23:34 jberger at the end of a request/response cycle does it go away?
23:34 sri nope
23:34 jberger how long-lived is it?
23:35 sri for as long as you like
23:35 sri you establish an arbitrary number of streams
23:35 jberger how does it work with preforking servers?
23:35 anon joined #mojo
23:35 sri it's just one tcp connection
23:35 sri so you have to handle them all in one worker
23:36 jberger how can that be arranged?
23:36 jberger oh it doesn't have to
23:36 jberger it reuses the session indefinitely
23:36 sri *can*
23:36 jberger at least until the connection is dropped
23:37 woz joined #mojo
23:37 jberger so would you trust this session id to be say the session id for looking up a session storage?
23:37 sri not at all
23:38 jberger right, so things like a session cookie aren't going away
23:38 sri like, would you trust the file descriptor of the tcp connection currently?
23:38 sri it's nothing else
23:38 jberger no, I was just trying to get a sense of the scope
23:38 jberger ok
23:39 sri a streams are basically just keep-alive connections multiplexed on a single tcp connection
23:39 sri s/a//
23:39 jberger hmmmm, and the frames interleave?
23:40 sri yes
23:40 sri that's why they are usually quite small
23:40 sri and http messages get split up into many small frames
23:40 jberger can some body frames arrive before all of the header frames do?
23:41 jberger if so, that's gonna be a nightmare
23:41 jberger although I guess you don't need to parse the body as it arrives
23:42 sri no, i don't think that's possible
23:42 jberger is there a signal that ends the arrival of headers?
23:42 sri http://chimera.labs.oreilly.com/books/1230000000545/ch12.html#_binary_framing_layer
23:42 jberger ok, so the first body frame is that signal
23:42 sri that description is very good
23:42 sri awesome book
23:43 sri just don't read the prioritization part, it will give you a headache!
23:43 jberger hehe
23:44 jberger I like what I'm reading already, very understandable
23:44 jberger ok /me has to eat something
23:44 * sri has to sleep
23:44 jberger hopefully I'll get a little more chance to work on this tonight
23:44 jberger sri: nn
23:44 sri o/
23:45 jberger \o
23:45 jberger btw, I don't care if this is the final cut (or even an intermediate cut) of the refactoring
23:45 jberger someone had to make a first attempt to see what works and what doesn't
23:50 asarch joined #mojo
23:53 disputin joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary