--- Log opened Mon Feb 09 00:00:45 2009
01:54 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/75 test cases failed. Check http://buildbot.happstack.com/ for details.
02:05 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
02:30 < mae_> yay, it built :)
03:01 < wchogg_> mae_ : I lost my connection for a sec so I don't know if you saw it, but I'm going to be maintaining Crypto from now on.
03:03 < wchogg_> mae_ : The real relevance being that I'll be in a good position to try & get us weaned off of Happstack.Crypto, I believe.
03:15 < wchogg_> Yeah, good riddance to me.
03:15 < wchogg_> Jerkface.
03:16 < Axman6> yeah, what a dick!
03:24 < wchogg_> Axman6 : Whoah whoah whoah.  Only I get to talk to me like that.  We stick together, ya see?
03:26 < Axman6> hey man, i just tell it how i see it
03:26 < Axman6> or i make crap up
03:27 < wchogg_> So what you're saying is that you're a crappy person?
03:29 < Axman6> yeah, exactly, you got a problem with that?
03:30  * Axman6 goes to watch top gear
03:31 < wchogg_> I know I'm tired.  I was trying to ask what time zone you're in, but I started to type "how old is it where you are?"
03:34 < wchogg_> In fact, I think I'm going to start saying that on purpose just to be confusing.
03:54 < h_buildbot> Build for ghc-6.8.3 OK. Test suite ran. 15/75 test cases failed. Check http://buildbot.happstack.com/ for details.
04:02 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 16/75 test cases failed. Check http://buildbot.happstack.com/ for details.
04:53 < koeien> Saizan_: ping
04:53 < koeien> Saizan_: if nobody responds to my mail, I think we can make something up :)
06:11 < koeien> ?bot
08:26 < Saizan_> koeien: i guess :)
08:27 < Saizan_> koeien: maybe reply saying that we'll change the current semantic, so people get scared and is more inclined to talk :)
10:12 < koeien> Saizan: yes that may be a good idea :)
10:13 < koeien>  meh, top-replying is annoying
10:29 < koeien> replied
11:27 < mae_> koeien: if you can think of a way which streamlines things which changes the semantics also, go ahead and do it :)
11:27 < mae_> the xml parsing stuff is not really needed imo, the xml output is useful for those who use xslt though
11:29 < mae_> wchogg_: ok so you'll roll the Happstack.Crypto stuff back into Crypto?
11:29 < mae_> sounds great
11:29 < mae_> really benefits the community too :)
11:29 < koeien> mae_: why is parsing not useful?
11:30 < mae_> koeien: it is, but give me a use case
11:30 < koeien> suppose you get a POST with data you want to inject into your state?
11:31 < koeien> you parse it & put it in
11:32 < koeien> mae_: btw, i explained how to do SSL + Happstack on http://huygens.functor.nl/blog/?p=21 . it would be nice to have this natively some time in the future though
11:32 < mae_> koeien: but post data isn't in xml format...
11:33 < koeien> mae_: why not?
11:33 < mae_> unless your webservice receives xml data explicitly in a field
11:33 < koeien> mae_: not from a regular web request, no, but it could be if you communicate with other systems
11:33 < mae_> true
11:33 < mae_> so useful for a webservice
11:33 < koeien> at a company i worked for, such things were common :)
11:33 < mae_> ok, what do you propose doing as far as 'changing the semantics' anyhow?
11:33 < koeien> not really anything concrete right now
11:34 < koeien> i don't think you can get "fuzzy parsing" right
11:34 < koeien> XML is not very "fuzzy" anyway
11:34 < mae_> koeien: native ssl is a mess, and I don't see that in our goals for awhile, if ever :)
11:34 < koeien> mae_: okay, then it will be apache (or lighty -- i think you can do this that way as well, not sure)
11:34 < mae_> perhaps if crypto gets beefed up to the point where all we have to do is drop in the support
11:35 < koeien> mae_: doesn't this depend on OpenSSL ?
11:35 < mae_> koeien: yep you can use the proxy method from any popular webserver
11:35 < mae_> koeien: well thats the point, we have to get openssl involved
11:35 < mae_> which is messy
11:35 < mae_> the more we can keep native haskell, the better
11:36 < koeien> mae_: you introduce apache just for ssl, this seems messier to me :) but i don't know how easy it is to get SSL support
11:36 < mae_> not every webapp needs ssl
11:36 < koeien> of course not
11:36 < mae_> and this is the concept behind an 'application server'
11:36 < koeien> hmm, yeah ok
11:37 < mae_> just enough http to interface with all the modern stuff
11:37 < koeien> anyway, it's nice that SSL-support can be done easily
11:37 < koeien> using apache
11:37 < mae_> koeien: yep
11:37 < mae_> koeien: and most people are comfortable configuring apache these days
11:37 < mae_> so its not too much of a stretch
11:38 < koeien> mae_: the same with MySQL :) /me evades stones thrown at him
11:38 < mae_> all the important bits are still kept in the appserver
11:38 < mae_> ssl just tunnels what our appserver is doing
11:38 < mae_> adds a layer of indirection, if you will
11:38 < mae_> koeien: true, i think MACID needs to be made alot more friendly
11:39 < mae_> koeien: this is one of my main goals of 1.0
11:39 < koeien> mae_: yes of course, that's why it's called "transport layer security" :)
11:39 < mae_> it needs to be "easier" to setup than mysql for the average haskeller to be compelling
11:39 < koeien> TLS at least
11:40 < mae_> and along the lines of easier to interface with
11:40 < koeien> SQL is... bleh
11:40 < mae_> i would like to build some more TH / SYB stuff which auto-creates rest interfaces
11:40 < koeien> and native haskell types are *really* nice
11:40 < mae_> and you just plugin the query / update functions
11:41 < koeien> anyway, i could take a look at openssl's s_server also
11:42 < mae_> hm
11:42 < mae_> go for it :)
11:42 < koeien> yeah it's on my list :)
11:42 < mae_> although i'd rather you help out with the documentation effort right now
11:42 < mae_> or create some more test coverage
11:43 < koeien> taking a look at -Data
11:43 < mae_> particularly before 0.2 i want to have some test coverage for the multimaster stuff
11:43 < koeien> i'm completely unfamiliar with it
11:43 < mae_> with multimaster?
11:43 < koeien> yes
11:43 < mae_> me too :) that is part of the challenge
11:43 < mae_> we are all picking up the pieces to a certain extent
11:43 < mae_> i mean i've talked with lemmih
11:43 < mae_> so i have a rough outline
11:44 < koeien> hmm yeah although some people here are cheating by having knowledge already :)
11:44 < mae_> true
11:45 < koeien> the multimaster stuff is in ... ?
11:45 < koeien> -State, i suppose?
11:48 < Saizan> yeah
12:05 < dsrogers> Saizan: I've nearly solved that escape semantics problem.
12:05 < dsrogers> I broke out WebT into 3 monads, MaybeT, FinishT (which is almost, but not quite ErrorT), and FilterT
12:05 < dsrogers> and created typeclasses for all of them.
12:06 < dsrogers> and just created WebT as a composition of those three.
12:06 < Saizan> uhm, that might make it more complex to use?
12:06 < dsrogers> no, not really.
12:06 < dsrogers> though it does make the constructors more complex.
12:06 < koeien_home> what about efficiency?
12:06 < Saizan> btw there's a MaybeT package on hackage, maybe we want to use that
12:07 < dsrogers> indeed.
12:07 < dsrogers> I did.
12:08 < dsrogers> It has all the same semantics, except now there is a WebT type class.
12:08 < dsrogers> which means you can use it with arbitrary monad transformers.
12:08 < dsrogers> which is a HUGE benefit.
12:08 < dsrogers> no need for special casing sticking the ErrorT into the WebT
12:09 < dsrogers> and it's definately not source compatible.
12:09 < dsrogers> well it is if you don't call the constructors explictly.
12:09 < koeien_home> wasn't that a 0.2 goal? :(
12:09 < dsrogers> well I haven't commited it.
12:09 < koeien_home> yeah of course.
12:10 < dsrogers> or I should say, noone has commited it.
12:10 < Saizan> well, the patches already applied already break compatibility
12:10 < dsrogers> 'cause I can't.
12:10 < dsrogers> I don't think they do?
12:10 < koeien_home> that's too bad. I am not sure whether HAppS-compatibility was a goal, i thought it was at least for 0.1 & 0.2
12:10 < Saizan> but we also have "remove HAppS-State dep from HAppS-Server" in the 0.2 milestone
12:11 < dsrogers> well let me rephrase.  I can fix my patch so that it has source compatibility
12:11 < Saizan> and that at least requires you to change imports
12:11 < dsrogers> I understand how to do that now that I've gone and solve the more general problem.
12:12 < Saizan> dsrogers: but you're going to change the constructors for WebT and/or their meaning, no?
12:13 < dsrogers> hmm... yeah, the Escape constructor changed semantics.
12:13 < dsrogers> though, I also added enough methods that there is no longer a reason to export the constructors.  There is already a function to do what you want.
12:13 < dsrogers> so, you're right.
12:14 < Saizan> mae_: how much compatibility is 0.2 supposed to keep wrt HAppS ?
12:15 < mae_> Saizan: per blog post about the 'version # paradigm shift' I am not worried too much about backwards compatibility
12:16 < dsrogers> Saizan: I think I can limit my damage to breaking the WebT constructors.  And provide some docs on how to convert to the functions with equivilent functionality.
12:16 < mae_> but at the same time, we should change the semantics only in ways that would improve readability and/or intuition for our end-user developers.
12:17 < mae_> Saizan, dsrogers: I would say if something significant needs to change, make a new function name which reflects the semantics and use the deprecate pragma on the old one
12:17 < mae_> in this way we can still keep compatibility but warn that we will be removing support eventually
12:17 < dsrogers> mae_: you can't do that with constructors.
12:18 < mae_> dsrogers: ? why not ?
12:18 < dsrogers> because I don't know how, it would seem.
12:18 < dsrogers> :-)
12:18 < mae_> well ok
12:18 < mae_> if you have a constructor with new semantics
12:18 < mae_> can't you call it
12:18 < mae_> WebT_New for instance?
12:19 < mae_> or rename the old one to
12:19 < mae_> WebT_Old
12:19 < mae_> and deprecate it?
12:19 < dsrogers> yeah, I can.
12:19 < Saizan> dsrogers: i think it's best to design what looks more elegant and easy to use at this point, but also still supporting a way to obtain the old semantic which apparently is useful for our users
12:19 < dsrogers> And push all the new WebT_features into WebT_Old.
12:20 < mae_> yeah
12:20 < mae_> i'll note that in the release
12:20 < dsrogers> Saizan: well the functional semantics, I'm not changing
12:20 < dsrogers> I
12:20 < dsrogers> I'm essentially adding features.
12:20 < Saizan> _Old is ugly :\
12:20 < dsrogers> yes it is.
12:20 < Saizan> yeah
12:20 < mae_> Saizan: the idea is that _Old will dissapear
12:20 < mae_> eventually
12:21 < mae_> we are just keeping it to be nice
12:21 < mae_> we can drop support in say 0.3 or 0.4
12:21 < Saizan> we aren't nice, since you've to change your source anyway
12:21 < mae_> haha
12:21 < mae_> Saizan: so what do you propose we do?
12:21 < dsrogers> I might be able to use type to alias the old constructors.
12:21 < Saizan> mae_: just make the break evident
12:22 < Saizan> mae_: since we still provide functions to get the old behaviour
12:22 < koeien_home> yes i won't waste time with "deprecations" now
12:22 < Saizan> we could decide to hide the constructors for WebT
12:23 < koeien_home> s/won't/wouldn't
12:23 < mae_> ok, then lets forget about the deprecations
12:23 < mae_> but I will need you guys to provide an example / synopsis of how these things have changed
12:23 < dsrogers> yeah, no problem.
12:23 < mae_> so I can include that in the release notes
12:23 < mae_> kk
12:24 < mae_> i suppose the holdouts can continue to use 0.1 or happs
12:24 < mae_> when we reach the breaking point of shininess they will switch
12:26 < dsrogers> I'll have this in a few days.  I actually have to go to work now, since it's already 9:30 am here.
12:27 < koeien_home> mae_: yeah once we reach "stability"/nirvana we certainly have to worry about it :)
12:28 < dsrogers> I'm trying to think if there is any good reason to allow WebT constructors...
12:28 < dsrogers> do other monad transformers expose their constructors?
12:29 < Saizan> many do
12:29 < HugoDaniel> hi happstackers
12:29 < koeien_home> hello
12:29 < HugoDaniel> is a template system really needed ?
12:29 < mae_> template system ? :)
12:29 < HugoDaniel> html templates suck big time
12:29 < dsrogers> you don't need one.
12:29 < mae_> HugoDaniel: you are not forced to use one
12:29 < Saizan> HugoDaniel: it's probably nice to provide support for those that want to use one
12:30 < HugoDaniel> i really enjoyed the happs approach of using jquery in the client and handlers on the server
12:30 < mae_> HugoDaniel: that approach is still perfectly valid
12:30 < HugoDaniel> the html code doesn't turn into that big ball of twine
12:31 < HugoDaniel> besides, since we are assuming the user can run his own http server, why not just allow things to be done the correct way, and avoid html templating at all ?
12:31 < mae_> I hate to be "that guy", but what about accessibility for spiders and non-javascript browsers?
12:31 < koeien_home> am i the only one who kinda likes templates? :)
12:31 < mae_> koeien_home: i think it is important to have quick and dirty templates
12:31 < mae_> : )
12:32 < Saizan> HugoDaniel: happstack is still going to be a framework where you can make your own choices about such questions
12:32 < HugoDaniel> yes, i didn't thought of that mae
12:32 < mae_> but again, you have the flexibility to do whatever you want
12:32 < HugoDaniel> :)
12:32 < koeien_home> i like django's templating system
12:32 < Saizan> HugoDaniel: we just want to make the possible alternatives easier to use
12:32 < HugoDaniel> yes, i see, nice going :)
12:32 < koeien_home> mae_: yeah we should either ship a templating system or describe how to use one :)
12:33 < HugoDaniel> i've been reading out on the ML about being simplifying the handlers stuff
12:33 < HugoDaniel> i like the way handlers are :)
12:33 < Saizan> what are handlers in this context?
12:33 < Saizan> SimpleHTTP?
12:33 < HugoDaniel> sorry, ServerPartT's
12:33 < HugoDaniel> yes that
12:34 < Saizan> ah, yeah, we were discussing that
12:34 < HugoDaniel> btw, is there any special linux version that uses the sendfile system function ?
12:34 < koeien_home> 'sendfile'?
12:34 < HugoDaniel> since i will be runing my own http server, i would like it to be pretty fast
12:35 < HugoDaniel> yes, for static file serving
12:35 < HugoDaniel> that would probably require a lot of hacking and slashing
12:35 < HugoDaniel> http://linux.die.net/man/2/sendfile
12:36 < HugoDaniel> i would gladly do it, but im filled with work right now :(
12:36 < mae_> its possible but not a priority right now
12:36 < mae_> in the meantime you can always have apache or lighty or nginx server up static files
12:36 < mae_> and proxy the rest through
12:36 < koeien_home> also we have to be sure to maintain cross-platform compatibility
12:36 < HugoDaniel> well
12:36 < dsrogers> oh right.  I forgot.  Since there is a WebT typeclass it can behave like a proper monad transformer.  Which means there is a natural way to pull all the WebT logic into ServerPartT
12:37 < HugoDaniel> what im doing right now, is read up all the files in a directory tree on the server startup, then im wrapping the simpleHTTP with a reader monadT, and serving the files through it
12:37 < HugoDaniel> it allows a bit of http request manipulation and url handling when mixed with the ServerPartT's, since the file structure is defined by me
12:37 < Saizan> reading the contents?
12:38 < HugoDaniel> well, not quite
12:38 < HugoDaniel> lazyness
12:38 < HugoDaniel> i just go through them
12:38 < HugoDaniel> the first access is slow, but then its okey
12:38 < HugoDaniel> files are kept inside a lazy bytestring
12:38 < HugoDaniel> the data structure has some other semantic information
12:39 < HugoDaniel> that might be usefull, like the libmagic output, and im planing on adding more as needed
12:39 < dsrogers> HugoDaniel: can you link me an example of that somewhere?
12:39 < HugoDaniel> like image file dimensions, media length (music length, video duration), etc...
12:40 < dsrogers> I'd like understand it so I can possibly incorporate that style into the documenation.
12:41 < HugoDaniel> dsrogers: not yet, it is only working on my machine, i will write about it when i find some time
12:42 < dsrogers> kk
12:42 < dsrogers> off to work!
12:42 < HugoDaniel> well, the best thing would be to allow so rdf api for semantic information related to what is being served... im not sure on how the semantic web thingy is going on, but it seems to me like a good approach
12:43 < HugoDaniel> it would really kick ass seeing that kind of stuff as an "happstack extra"
12:43 < mae_> happstack-contrib
12:43 < mae_> : )
12:43 < HugoDaniel> semantic appendable information framework for your kinky wet fantasies
12:43 < mae_> wow.
12:43 < mae_> hawt
12:46 < HugoDaniel> http://protempore.net/rdf4h/
12:46 < HugoDaniel> i guess it would also be nice as an api for MACID or what it is being replace for
12:46 < HugoDaniel> to allow remote access
12:46 < HugoDaniel> and the possibility of macid being placed on other servers than the one serving the http request
12:47 < mae_> there is already this support
12:47 < HugoDaniel> because sql is a big time fail
12:47 < mae_> happstack-state multimaster
12:47 < HugoDaniel> ohh sweet
12:47 < mae_> and you are not forced to use the http server with happstack-state
12:47 < mae_> you can use it independently
12:47 < HugoDaniel> hmm
12:47 < mae_> although the multimaster stuff is not well documented
12:47 < HugoDaniel> im currently using postgresql
12:48 < mae_> the next release should have some more documentation and tests for it
12:48 < HugoDaniel> ill probably use state for session handling
12:48 < HugoDaniel> but im not yet there..
12:48 < HugoDaniel> well, back to work, thanks for the attention span :)
16:29 < mae_> so hey gents / gentlemen
16:29 < mae_> what happens if you run two processes on the same appstate
16:29 < mae_> will they bork each other
16:35 < Saizan> i'd guess so
16:51 < koeien> is there a portable way to lock it? :)
16:52 < stepcut> mae_: don't do that
18:33 < mae_> stepcut, Saizan, koeien: yeah i was just asking because i'm trying to think of possible caveats for macid
18:33 < mae_> perhaps we should add a locking mechanism
18:33 < mae_> something that creates a folder
18:34 < mae_> or the likes
18:34 < mae_> with a unique identifier that a process creates on startup
18:34 < koeien> a pidfile, you mean?
18:35 < stepcut> has anyone tried to see what currently happens?
18:36 < mae_> koeien: not a pidfile
18:37 < mae_> problem with a pidfile is that someone could feasibly use forkIO and start the state system more than once (within the same pid)
18:37 < koeien> no
18:37 < mae_> what i suggest is that we generate a random (unique) identifier or hash and put that in the folder name
18:37 < koeien> it's convenient to store the pid
18:37 < koeien> so you can look up the process easily
18:37 < mae_> and the lock is generated when startSystemState is called
18:37 < koeien> if there is a pidfile, you refuse to run, even if the pid is the same
18:38 < koeien> but this is pretty nonportable, you'll have to have an exception for systems where there is no such thing as pid
18:38 < mae_> koeien: true but we leave enough flexibility to shoot yourself in the foot (i.e. they can start the state system whenever they want).
18:38 < koeien> mae_: nah i just propose to store the pid instead of your random hash
18:38 < koeien> why use a hash at all?
18:39 < koeien> just create a file called '.lock'
18:39 < koeien> leave it empty
18:39 < mae_> what i'm suggesting is we integrate the lock inside Happstack.State.Control
18:39 < mae_> sure ok
18:39 < koeien> (or put the pid in it :))
18:39 < mae_> a lockfile inside the state folder?
18:39 < koeien> for example
18:39 < koeien> requires manual intervention if the program is shut down
18:39 < stepcut> mae_: not all happstate-servers have disk access
18:40 < koeien> then you could use shared memory
18:40 < koeien> but that is probably even less portable
18:40 < mae_> http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=1288#a1288
18:40 < mae_> like this
18:40 < mae_> just touch a lockfile
18:40 < mae_> inside the same folder as the checkpoints and events
18:40 < stepcut> mae_: but the checkpoints and events might not be stored on disk in a folder...
18:40 < koeien> yes, (i still suggest to store the pid in there if it's on a compatible system)
18:41 < koeien> stepcut: then, where?
18:41 < mae_> stepcut: if the state is in memory for a particular program using Happstack.State, then it is local data and thus has no risk of corruption
18:41 < koeien> mae_: right, that was the point i was starting to make :)
18:42 < stepcut> mae_: right, so this should be something  specific to the saver, right?
18:42 < mae_> stepcut: however, right now the _local state is unique based only on the name of the executable
18:42 < mae_> _local == on disk state
18:42 < mae_> (for durability)
18:42 < mae_> stepcut: right
18:42 < mae_> so what i am suggesting is that
18:44 < mae_> we add a locking mechanism
18:44 < mae_> to the FileSaver store i guess
18:44 < stepcut> yeah
18:45 < stepcut> doesn't make sense for the memory saver
18:45 < mae_> right
18:45 < stepcut> might for S3, though I am not sure if that one exists/compiles anymore
18:46 < stepcut> but, one for filesaver would be quite nice
18:56 < mae_> read this:
18:56 < mae_> http://code.google.com/p/happstack/issues/list?thanks=61&ts=1234223762
18:56 < koeien> agreed with (1)
18:57 < koeien> you won't stop people killing your process with -9 but there's nothing you can do anyway
18:57 < mae_> right
18:57 < mae_> then the lock has to be manually removed
18:57 < mae_> or we simply warn them that they might hose their data when the lock is removed
18:57 < mae_> and offer to do it for them
18:58 < koeien> yep. refuse to start by throwing an exception explaining the situation if the lock is there. otherwise create it
18:58 < mae_> 'if you want to confirm type 'YES REMOVE THE LOCK EVEN THOUGH DATALOSS MAY OCCUR''
18:58 < mae_> or maybe thats too annoying :)
18:58 < koeien> nah just let people remove the lock
18:58 < koeien> you may want to check for other instances of your process first
18:58 < stepcut> the WARNING should be clear that you will only see corruption if a process is already running
18:58 < koeien> ps aux | grep $YOUR_APP
18:59 < mae_> stepcut: please put comments on the issue :)
18:59 < mae_> otherwise we will lose track
19:00 < stepcut> done
19:01 < koeien> i think it's easier not to have any interaction at all. what do you think?
19:01 < mae_> koeien: yeah i agree
19:02 < koeien> anyway, i'm off to bed
19:02 < mae_> ok nighty
19:18 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
19:20 < h_buildbot> Build for ghc-6.10.1 failed. Check http://buildbot.happstack.com/ for details.
22:12 < seafood> Hey guys, just thought I'd say it's really impressive to see what you have managed to organise in just a matter of weeks.
22:30 < stepcut> seafood: thanks!
--- Log closed Tue Feb 10 00:00:05 2009