--- Log opened Fri Dec 25 00:00:44 2009
22:17 < cdsmithus> Anyone got any good examples of doing sessions in happstack without happstack-state?
22:21 < stepcut> cdsmithus: I have an example, but it requires happstack 0.5, which hasn't been started yet :)
22:21 < stepcut> what do you expect session support to provide?
22:22 < cdsmithus> Hmm... mainly, I actually just want to be able to save a function that I build when I'm generating a page, and then call it once I get the response.
22:22 < cdsmithus> Namely, a form parameter parsing function.
22:24 < cdsmithus> I don't even need it to do cookies, I suppose.  Could just embed a token into the page and use that for the lookup... so perhaps I just want an IORef.
22:27 < cdsmithus> I suppose the reason I'm asking is that I wonder if there's a sort of consensus way to do it (that's not terribly complex), rather than rolling my own.
22:29 < stepcut> do you need some way to expire that information if the Response never comes?
22:30 < cdsmithus> I suppose in the long run, yes that would be nice. :)
22:30 < cdsmithus> Honestly, I'm just playing at the moment.  So "need" is a funny word.
22:31 < stepcut> what happens if there are multiple users?
22:32 < cdsmithus> Shouldn't be a problem; since the key I embed into the page (I suppose I'll need to do this even if there are cookies used, since web browsers are non-linear) should be unique, it will be used to work out the abiguity.
22:33 < stepcut> why can't you calculate the function after the Response is returned?
22:34 < cdsmithus> Umm, because I hadn't thought about doing it that way I suppose.  I'm not sure, off-hand, if that would be possible.
22:34 < cdsmithus> I think it might, in some cases, involve repeating some rather expensive calculations.
22:35 < cdsmithus> (but I can't say what "expensive" means in that sentence)
22:35 < stepcut> would be nice if the Response contained all the information you needed to calculate the result, and then you wouldn't need sessions at all
22:36 < cdsmithus> Yes... I agree that would be nice; but it seems to wreak havoc on the programming model.
22:36 < stepcut> so, you need to store an actual function?
22:37 < cdsmithus> Again, "need" is funny... but that's sort of the goal of my experiment.  To see if I can make it easier to build certain very chageable user interactions by programmatically generating HTML, and the form submit parser, in parallel
22:39 < cdsmithus> I'm sure that, given the same data, I can repeat the same procedure, and construct the form data piece in the next request.  That's also an option, but not how I'd originally conceived of it./
22:39 < stepcut> if you require a function, then you definitely can't use happstack-state.. or any form of serialization. So, I guess something with an IORef would be the way to go?
22:39 < stepcut> cdsmithus: that is kind of how formlets work
22:40 < cdsmithus> Yeah, it looks like it.  Though on second (or third) thought, I think I may still have something like sessions, just because I really can't discard that function until I've decided the user is gone.  Back buttons and all
22:41 < stepcut> yes -- another reason why it is nice if you can make it stateless ;) But if you can't, then you can't. What does it mean to have a 'session' though?
22:44 < cdsmithus> What I meant was to essentially have a global IORef (Map String (Map String MyFunc)).  And then a timer to retire keys in the outer map, and a mechanism to set a cookie to associate each user interaction with a key in the outer map.
22:46 < cdsmithus> Well, slightly more complex, because you'd have to track the time that each "session key" in the outer map was last touched... but, same idea.
22:47 < stepcut> there is not anything like that in happstack already, but it should be easy to do.. just call newIORef, and setCookie / mkCookie
22:48 < stepcut> the timer loop is a bit trickier.. I have some code that demos how to do that and I hope to make it more accessible in 0.5
22:49 < cdsmithus> The idea of recalculating the function when handling the response sounds nice... I'm just concerned that it will be limiting.  For instance, it would surely be out-of-bounds to do any I/O where the choice of controls on the form would depend on the results of the I/O.
22:51 < cdsmithus> Writing the timer loop wasn't my concern... my concern was that I might write it, and then realize that there was something already out there.  So, that's my answer I suppose.  Thanks!
22:51 < stepcut> nothing like that exists .. it wouldn't really scale up
22:52 < stepcut> the function would be  stuck on the original machine that you made the request to -- so if you had a cluster, you would have to route all the following responses from the same user to the same server
22:53 < stepcut> and you wouldn't be able to persistently store data across restarts
22:53 < cdsmithus> True.  That's pretty much a universal problem with "session" stuff in web applications, as far as I've seen.
22:53 < stepcut> also, there are issues with IORef and atomic updates
22:53 < stepcut> and deadlocks
22:54 < stepcut> if you implemented your sessions on top of happstack-state, they could be replicated automatically. But you can't store functions in happstack-state.
22:54 < cdsmithus> Do you mean "use an MVar"?  Or "there's no easy way to do it"?
22:55 < stepcut> with MVar you can have other problems I think. if the MVar takes the variable, and the thread dies, then I think all the other threads would deadlock?
22:55 < stepcut> or if the thread simply takes it and never returns it?
22:56 < cdsmithus> True... but there's  be a very limited set of code that handles the MVar.  It would basically amount to "take the MVar, update the last mod time and add a new key'value pair to the Map, then replace it".  Nothing that should be terribly prone to dying.
22:58 < stepcut> in your code, yes. As a general mechanims... not so much.
22:59 < cdsmithus> I see.
23:00 < cdsmithus> Well, thank you for the time.  I'm pondering how much flexibility could be retained without actually storing the function...
23:01 < stepcut> dunno.. for what you are doing, it sounds like an IORef or MVar is the way to go, because the part you are interested in innovating is elsewhere.. if it doesn't work, then the IORef will be irrelevant anyway :)
23:01 < stepcut> if it does work, then you can worry about porting it to happstack-state
23:02 < stepcut> formlets do allow you to do IO when generating the form, and when validating the Response. But the trade off is that you can do it wrong :)
23:03 < cdsmithus> Yes, I can see that.  I'm definitely hoping for a certain level of "if it type-checks, then it's correct" nature.
23:03 < stepcut> well, the general formlet mechanim allows you to do IO. In a specific program you can use more restricted types
23:03 < cdsmithus> Well, in my case, that would be "if it type-checks, and certain low-level pieces are assumed to be correct..."
23:04 < stepcut> :)
23:05 < cdsmithus> I did notice a similarity between what I'm doing and the continuation thing posted to the mailing list recently (except that the continuation thing spans several requests).  The similarity to formlets as well is interesting.
23:05 < stepcut> let me know how it works out.. there is definitely a lot of innovation left in that arena
23:06 < stepcut> the continuation stuff looks interesting too
23:06 < cdsmithus> Yes, it looks nice, definitely.
23:07 < stepcut> the nice thing about all these technologies is that they don't require modifications to core happstack. So people can easily experiment with them
23:07 < stepcut> and we don't have to try to make a one-size fits all solution
23:09 < cdsmithus> Yes, the chance to experiment is great.  Unfortunately, a two-edged sword when trying to sell the idea to non-Haskell fans who can say things like "if we used Ruby, then every Ruby web developer in the world would be familiar with how we wrote our application, because it would be a Rails application."  Not sure how true that is, not being a Ruby person.
23:10 < cdsmithus> But, that's my fight for next month. :)
23:15 < stepcut> :)
23:16 < stepcut> yeah, but if the one-way doesn't work, then they are stuck :p
23:19 < stepcut> I think that in most non-trivial web applications, a vast majority of the code is application specific anyway, and so no one is just going to be able to walk in and understand what is going on
23:21 < stepcut> and when you don't make it easy for developers to integrate the way that works for their site needs, it doesn't stop them. It just forces them to build an ad-hoc system on top of the 'the one, true way' you provided. Which is far more complicated than what they would have developed if they didn't have to work around your systetm
23:23 < stepcut> if you look at a site like facebook -- in theory it is a LAMP system. But they don't use MySQL 'the right way'. All they don't use ACID, or transactions, and all their tables have only two columns in them. Rather than do the queries in SQL, they just use SQL to do a really lightweight query, and then do all the real query work in PHP. (Even though PHP is far slower, it is much easier for them to add more PHP servers to process the
23:23 < stepcut> results than it is for them to increase their SQL database pool to handle the 'faster' SQL queries).
23:24 < cdsmithus> Yes, I agree.  And the application we're looking it is definitely not just a standard database app... the way we're hoping to write it, trying to go the templates-and-plug-in-values route is going to be way more trouble than help.
23:25 < cdsmithus> which makes me doubt the value of a lot of the traditional sort of frameworks that are built around a template system
23:49 < stepcut> :)
23:51 < stepcut> someone might be working on a library so that we can use django templates with happstack. Would be a good way to ease the transition and make happstack less scary. Plus, that type of templating is useful in some cases
--- Log closed Sat Dec 26 00:00:46 2009