04:28:33 <gabriela> hola!
18:45:27 <stepkut> if you have a connection open to a database (postgres, acid-state, etc) and the remote server restarts -- what is the most sensible way of handling that on the client side?
19:19:51 <mm_freak> stepkut: reconnect?
19:21:06 <mm_freak> if you want to block until the connection is reestablished you can either use a separate thread and block on MVars or use a monad that allows reentry at the failure spot
19:21:23 <mm_freak> the former is easier to do, and for the latter you could use ContinueT or something
19:27:18 <uniquenick> do I have to worry about accidently starting up two copies of an app that uses acid-state, and them clobbering each other's data?
19:33:26 <mm_freak> uniquenick: probably
19:43:08 <stepcut> uniquenick: in theory, no.. we create lock files now that should stop you from being able to start acid-state twice I believe
19:43:31 <stepcut> mm_freak: the question is, who/what/when/where does that reconnection happen.. in the user code? in the library?
19:44:06 <stepcut> one difficulty is that if you issued a remote update and the connection gets dropped.. you don't really know if that transaction completed or not
19:44:31 <mm_freak> stepcut: depends on the context…  a web framework?  a database abstraction?
19:44:39 <stepcut> in acid-state
19:45:04 <mm_freak> are you making a new .Remote?
19:45:10 <stepcut> yes-ish
19:45:41 <stepcut> it's the old Remote with a bunch of changes
19:46:07 <stepcut> I need three things: (1) ability to add TLS support (2) authentication support (3) do something sensible when the server restarts
19:46:50 <stepcut> not really sure how postgres users handle this
19:47:03 <mm_freak> i see
19:47:13 <mm_freak> well, postgres users just reconnect
19:47:14 <stepcut> the normal unix way is to through your hands up, raise an error, and make the end-user deal with it
19:47:36 <stepcut> so, they get some sort of exception, and have no idea if the 'update' completed or not ?
19:47:44 <mm_freak> yes
19:48:14 <stepcut> I'm not sure that worse is better, but I don't really have a better plan at the moment
19:48:57 <mm_freak> well, you can deal with it using transaction ids
19:49:10 <mm_freak> client reconnects and just retries the transaction using the same id
19:49:19 <mm_freak> if the server responds, "already done that", then the client moves on
19:49:26 <stepkut> ah
19:49:41 <stepkut> so, we could add something like that to acid-state as well then
19:49:47 <stepkut> though, not today
19:49:54 <stepkut> because I don't have time for that :)
19:50:03 <mm_freak> well, don't wait too long =)
19:50:15 <mm_freak> adding that concept later may be hard
19:52:38 <stepkut> it is already later
20:02:07 <stepkut> acid-state does not currently have any exception type
20:02:27 <stepkut> it just calls error in the few places it can fail when something goes really wrong
20:02:46 <mm_freak> btw, are you going to put this into the acid-state library itself?
20:02:55 <stepkut> but, in the event that the connection is lost, raising an acid-state specific Exception seems like a good way to go?
20:03:14 <mm_freak> because that's not strictly necessary and would make the library dependencies explode
20:03:21 <stepkut> ?
20:03:29 <stepkut> it is already in acid-state, I am just making it better
20:03:54 <mm_freak> yeah, i would take it out and make a separate library
20:04:00 <stepkut> because?
20:04:29 <mm_freak> because acid-state is great for general serialization…  i use it to save application configurations and stuff
20:04:48 <stepkut> taking it out would remove the dependency on network.. but that is part of haskell platform, so..
20:05:05 <mm_freak> only that?  no pipes?  attoparsec?  …?
20:05:29 <stepkut> the tls support requires HsOpenSSL, but that will actually go in a separate library
20:05:41 <stepkut> don't need attoparsec, it uses SafeCopy
20:06:08 <mm_freak> i see
20:06:43 <stepkut> and strict IO
20:07:16 <mm_freak> i say this because i've been prompted to evacuate the session handling stuff from my old fastirc package all the time
20:07:35 <mm_freak> because fastirc is itself a great IRC parsing library and that's about all most people need
20:08:15 <mm_freak> same for acid-state:  i'm sure only large-scale websites will really use the remoting stuff
20:09:09 <stepkut> the remote stuff was actually created mostly so you could inspect the running state using ghci.. which works for sites of any scale
20:09:41 <mm_freak> i see…  i never thought to do that =)
20:09:46 <stepkut> :)
20:10:13 <stepkut> clckwrks uses it so that you can do some administrative stuff from a command-line app
20:11:32 <stepkut> right now i need it because our web app is split into two pieces,but need to share a user database
20:13:53 <stepkut> in theory, we could have, acid-state, acid-state-local, acid-state-memory, acid-state-remote, acid-state-remote-tls, etc. But that seems a bit excessive
20:15:30 <mm_freak> acid-state, acid-state-remote
20:16:01 <mm_freak> the reason is that acid-state doesn't really depend on acid-state-remote and i can think of many applications that would require acid-state only
20:16:21 <stepkut> most applications don't depend on .Memory either
20:16:40 <mm_freak> right, but .Memory doesn't have any additional dependencies anyway
20:16:40 <stepkut> but.. so what?
20:16:55 <stepkut> acid-state-remote only adds network.. which is in haskell platform
20:17:16 <mm_freak> for now =)
20:18:36 <stepkut> .Remote also requires access to internals of acid-state that are not currently exported
20:18:51 <mm_freak> i see
20:19:31 <mm_freak> just as an idea:  what do you think of an SSH interface instead of a TLS interface?
20:19:52 <mm_freak> because then i could SSH into acid-state and get a REPL of some sort
20:20:14 <stepkut> :-/
20:21:06 <stepkut> SSH would be nice for other reasons.. but you wouldn't get a free REPL out of it
20:21:22 <stepkut> to get the free REPL you just use GHCi and connect using TLS ..
20:21:43 <stepkut> using SSH means you can use SSH authentication and security mechanisms, which is nice
20:22:15 <stepkut> originally, I had hoped to be able to use SSH port forwarding to forward the UnixSocket and not have to do anything special.. but that requires special patches to ssh or something
20:22:49 <stepkut> the new .Remote is somewhat extensible though
20:23:43 <stepkut> you have to provide a getSome, put, and close function. The normal version just uses the socket functions, and the TLS version uses the TLS read/write functions. So, in theory, you could add a .SSH version that plugs into that somehow
20:23:45 <stepkut> that is the idea anyway
20:24:54 <stepkut> if the network dependency was actually a problem.. we could still leave .Remote in acid-state, and just have acid-state-socket for unencrypted Remote connections