03:45:18 <donri> rlpowell: https://github.com/bitc/vim-hdevtools
03:45:38 <donri> sub-expression type inspection in vim (what i linked you before is slower and less reliable)
11:56:35 <rlpowell> donri: Thanks.
18:46:12 <LambdaDusk> hello... how to contribute/file an issue on happstack-clientsession?
18:49:29 <stepkut> what is the issue ?
18:50:19 <LambdaDusk> the issue is the ClientSessionMonad class
18:50:25 <stepkut> ok
18:50:33 <LambdaDusk> there's not enough instances to use it usefully
18:50:45 <stepkut> such as ?
18:51:32 <LambdaDusk> I will gist it briefly
18:53:22 <LambdaDusk> https://gist.github.com/3659453
18:53:22 <LambdaDusk> The trouble is the line 9 and line 18... I cannot find a combination where I can make my type MonadReader AND MonadClientSession at the same time - there's always some instance missing
18:54:04 <LambdaDusk> if I leave out MonadClientSession, it works, but then I lose the methods that come with it
18:54:09 <LambdaDusk> understand my problem?
18:54:39 <LambdaDusk> (extended the gist to the full source)
19:07:35 <stepkut> one moment
19:08:43 <LambdaDusk> ACTION waits.
19:10:55 <stepkut> oh, the issue is probably that ClientSessionT needs more instances
19:11:40 <stepkut> have to install some libraries first to test
19:13:15 <LambdaDusk> ok thanks
19:26:26 <LambdaDusk> ClientSessionT has a lot of instances, though
19:27:00 <stepkut> but not a MonadReader instance?
19:27:09 <stepkut> oh, it does
19:27:12 <stepkut> it is just not derived
19:27:27 <stepkut> anyway, these packages are almost done installing
19:40:20 <LambdaDusk> I thought MonadClientSession needs more instances
19:40:35 <stepkut> for the order you have the monad stacked, that seems to be true
19:41:02 <LambdaDusk> I tried out any order, in the hope there is one that might allow for both classes to be derived
19:41:56 <LambdaDusk> I just need the MonadReader for the server data like DB connection and acid-state stuff
19:43:20 <stepkut> adding this instance seems to fix things:
19:43:21 <stepkut> instance (Monad m, MonadClientSession sessionData m) => MonadClientSession sessionData (ReaderT r m) where
19:43:21 <stepkut>     getSession    = lift getSession
19:43:24 <stepkut>     putSession    = lift . putSession
19:43:27 <stepkut>     expireSession = lift expireSession
19:43:30 <stepkut>  
19:43:33 <stepkut> but, obviously, that should be added in happstack-clientsession
19:45:35 <LambdaDusk> seem to require  FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, is that bad?
19:48:17 <stepkut> nope
19:51:00 <stepkut> try happstack-clientsession 7.2.1 which I just uploaded to hackage
19:51:59 <LambdaDusk> does it have the same instances for StateT etc?
19:53:22 <stepkut> yup
19:53:31 <stepkut> ReaderT, StateT, WriterT, ContT, ErrorT, RWST
19:53:41 <LambdaDusk> great, thanks!
19:53:52 <stepkut> thanks for bringing it to my attention!
19:54:57 <LambdaDusk> thanks for fixing it so fast!
19:55:18 <stepkut> :)
19:57:51 <LambdaDusk> how secure can a clientsession be deemed?
20:02:09 <stepcut> depends who you ask
20:03:21 <stepcut> the data is encrypted and stuck in a cookie that is given to the user
20:03:46 <stepcut> in theory, that is more vulnerable than if they same data is kept server-side only
20:05:00 <LambdaDusk> what if someone copied the cookie?
20:06:30 <stepcut> what if they did /
20:06:44 <stepcut> someone copying the cookie is always a concern
20:07:55 <stepcut> if someone steals your auth cookie, is that better or worse than someone stealing your clientsession cookie?
20:12:50 <stepcut> I don't have a clear answer. Some people think that clientsession is perfectly secure. Other people (like me) are a bit less thrilled about the idea of storing sensitive data on the users machine, even if it is encrypted
20:14:55 <LambdaDusk> it does, however, save some trouble in the means of finding out whose session is this and also saves disk space
20:24:35 <stepcut> yup
20:24:51 <stepcut> also, you don't have to expire sesisons of people that will never come back, etc
20:25:38 <stepcut> there are many cases where clientsession is a great choice, even if there is a possibility that it makes your slightly more vulnerable
20:32:05 <LambdaDusk> I don't think that it matters anyway on a site like mine - there's no sensitive information
20:48:42 <LambdaDusk> when's the all-better, world-changing happstack 8 due?
20:49:11 <stepcut> well, first I am going to ICFP
20:49:20 <stepcut> then I am going to work on the new pipes based http backend
20:49:29 <stepcut> happstack 8 will be released in piecese
20:49:32 <stepcut> pieces
20:49:51 <LambdaDusk> huh
20:50:09 <rlpowell> Heh.  Maybe my work this past week is already obsolete.  :D
20:50:17 <stepcut> rlpowell: oh ?
20:50:34 <stepcut> rlpowell: you sent some patches for happstack-foundation + happstack-authentication or something?
20:50:39 <rlpowell> Yeah.
20:50:51 <rlpowell> Just emailed them, actually.
20:50:58 <stepcut> yeah.. to jeremy@n-heptane.com?
20:51:09 <rlpowell> I was kind of being silly; the stuff I did is much too high level to be obsoleted that easily, I think.
20:51:12 <stepcut> I know I have them, but I was having trouble pulling them up
20:51:30 <rlpowell> To: Jeremy Shaw <jeremy@seereason.com>
20:51:33 <stepcut> ah
20:51:41 <stepcut> I didn't check that email account yet, thanks
20:51:43 <rlpowell> It's all at http://vrici.lojban.org/~rlpowell/media/public/happstack/
20:51:55 <stepcut> I would very much like to show how to use happstack-foundation + happstack-authenticate
20:51:55 <rlpowell> I can show you the result, too, if you like.
20:52:09 <rlpowell> Yay.  There ya go, then.  Want to see it running?
20:52:13 <stepcut> sure
20:52:47 <LambdaDusk> I just thought of if it was possible to write a websockets thingie onto the new happs 8 server parser
20:53:11 <rlpowell> Just a sec; stripped it out to make the tars for you.  :)
20:53:28 <stepcut> LambdaDusk: we definitely want websockets in 8
20:53:41 <LambdaDusk> so do I
20:56:53 <LambdaDusk> are there efforts or can a lowly, hardly experienced haskeller try to contribute?
20:57:34 <stepcut> yes
20:57:37 <stepcut> one moment
20:58:43 <rlpowell> stepcut: http://vrici.lojban.org:8080/
20:59:27 <stepcut> nice
20:59:50 <rlpowell> stepcut: Note that when you go to "add auth", it no longer lists auths you already have.
20:59:56 <rlpowell> That took me, umm, like 3 days?  :D
20:59:58 <stepcut> ooo
21:00:09 <stepcut> sorry the happstack-authenticate code is not cleaner :)
21:00:22 <rlpowell> It's worth noting that over said 3 days I flew from Chicago to Toronto with a pair of twins, and also came down with a head cold.
21:00:30 <stepcut> hehe
21:00:30 <rlpowell> So it's not *that* bad, but I'm not the best haskeller yet.  :)
21:01:27 <rlpowell> 06-14:02 <     stepcut> ooo -- :D  I win!
21:22:27 <LambdaDusk> so, uh back to the topic of websockets...?
21:24:22 <stepcut> there is a websockets library
21:24:28 <stepcut> here is what would be useful
21:24:41 <stepcut> pretty much all I know about websockets is that it is kind of like TCP for the web
21:25:06 <LambdaDusk> stepcut: That one is tied to conduits, afaik...
21:25:09 <stepcut> it allows you to establish a long-lived two-way connection between the client and server
21:25:17 <LambdaDusk> among other things
21:25:41 <stepcut> it would be great if someone could simply describe what would be needed in order to support websockets in happstack
21:26:24 <LambdaDusk> stepcut: The websockets protocol starts with a special HTTP request, in which the server reponses with code 101 - switching protocols
21:26:24 <stepcut> like.. do we need a separate server that listens on a different port for websocket connections?
21:26:48 <stepcut> does the websocket connection some how get started in the middle of what looks like a normal Request / Response handling loop?
21:27:03 <LambdaDusk> then the connection is kept open via the same port, the entire protocol just changes
21:27:12 <LambdaDusk> yes
21:27:38 <stepcut> so, it looks like an normal http connection at first, but then you just ditch everything except the socket ?
21:27:42 <stepcut> and start over?
21:27:46 <LambdaDusk> it starts with an HTTP request, but the server responses with 101 - that connection is then kept open
21:28:01 <LambdaDusk> basically
21:28:16 <LambdaDusk> the connection is opened as HTTP but not closed with the response
21:28:51 <stepcut> so, when designing the new http backend, we should plan in websocket support from the start, even if we don't have it first
21:29:01 <stepcut> we need the mechanism for doing a protocol switch
21:29:02 <LambdaDusk> would be good
21:29:28 <LambdaDusk> HTTP 1.1 allows for a "connection: keep-open" header
21:29:40 <LambdaDusk> if I remember correctly, needs verification
21:30:31 <LambdaDusk> http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake
21:30:42 <LambdaDusk> there's this handshake
21:31:12 <LambdaDusk> and then everything happens via the ws: or wss: uri-scheme
21:32:56 <LambdaDusk> note the "Upgrade" header
21:33:57 <stepcut> cool
21:34:24 <stepcut> does it seem like it would be a lot of work to modify the existing backend to support this? Assuming we don't mind using the conduits based websocket library?
21:39:23 <LambdaDusk> basically it would need to allow that the handler can be switched when websockets are requested - I could even imagine some guard there
21:39:31 <LambdaDusk> but I honestly cannot tell
21:39:59 <LambdaDusk> I am not familiar enough with the inner workings of the happstack or websockets packages
21:40:56 <LambdaDusk> oh, sorry, it seems to be enumerator, not conduits with the current websockets
21:46:47 <stepcut> I will look into it when I start on the new backend
21:47:55 <LambdaDusk> http://hackage.haskell.org/packages/archive/websockets/0.6.0.2/doc/html/Network-WebSockets.html does it all right, though, with a sink
21:48:02 <LambdaDusk> pipes would be better there, though
21:48:05 <LambdaDusk> sink and source
21:48:45 <stepcut> :)
21:48:57 <LambdaDusk> think of it as an HTTP request where the body is still open to read and the response body is still open to write
21:49:03 <LambdaDusk> because that's what it is
21:49:27 <LambdaDusk> that is EventSource, basically, websockets only allow to do both at the same time
21:49:40 <LambdaDusk> Eventsources would be another nice feature
21:49:52 <rlpowell> stepcut: Lemme know when you're not using my controlv anymore.
21:50:18 <stepcut> rlpowell: done. eating lunch now
21:50:24 <rlpowell> 'k.
23:09:51 <donri> ACTION hates the expontential instances of mtl :(
23:10:19 <donri> can we figure out some alternative that still doesn't require lots of chains of "lift" in user code plz? :)
23:11:07 <donri> (re missing instance in clientsession)
23:43:56 <Igloo> You can make liftFoo functions with 2 instances, if you don't mind undecidable instances