--- Log opened Tue May 26 00:00:20 2009
08:54 < jmcarthur> mightybyte: i obviously didn't get it all polished and tested yesterday. it is possible i won't get a chance today either. i should be able to get it some time this week though, easily
08:54 < jmcarthur> i got hung up on how to migrate an IxSet and ended up giving up yesterday
10:23 < mightybyte> jmcarthur: I looked through some of your commits.  I was wondering why you took out the UserId.
10:24 < jmcarthur_work> i was going to ask you why it was there in the first place :)
10:24 < jmcarthur_work> that was one of the major changes i meant to ask about
10:25 < jmcarthur_work> would not be hard to put back if it must be there
10:27 < jmcarthur_work> but yeah, my logic... usernames are unique anyway. no need for a separate id
10:33 < jmcarthur_work> mightybyte, any thoughts?
11:02 < mightybyte> jmcarthur_work: The idea was that it would allow users to change their username.
11:03 < mightybyte> And it also prevents the problem of a user deleting his account, then another person registering that name and getting the first user's data.
11:05 < jmcarthur_work> the first reason didn't convince me, but i think the second one did
11:06 < mightybyte> And then there's always the lesser argument that userids are smaller than the full string username, so the rest of your data store can save space by storing uids instead of names.
11:08 < mightybyte> Also, removing it completely breaks my app.
11:10 < jmcarthur_work> heh
11:10 < jmcarthur_work> alright, i'll put it back
11:11 < mightybyte> I'm not usually a proponent of those size arguments, but since one of Happstack's goals is to provide ease of scaling and it also stores state in RAM, it seems like this could end up being a significant issue.
11:11 < jmcarthur_work> i think you are right
11:13 < mightybyte> It might also be good to throw in a comment explaining that it was an intenional design decision.
11:13 < jmcarthur_work> yeah. prevent future occurrences of what i just did :)
11:14 < mightybyte> Yep
11:16 < jmcarthur_work> thinking about it... is it ever really a good idea to allow somebody to register with a username that was previously taken?
11:18 < mightybyte> Well, if you do like I just did this morning and accidentally create a test user on the production site instead of the development site, then maybe.
11:18 < jmcarthur_work> not an argument against user ids, really, just thinking out loud
11:18 < mightybyte> Yeah
11:19 < jmcarthur_work> hmm... or perhaps an admin should be able to override that restriction, but it just seems like risky business to me. too easy to masquerade
11:19 < mightybyte> Although it seems like a fairly conservative policy.
11:19 < mightybyte> s/Although//
11:20 < jmcarthur_work> i can see cases where it would be fine to use an old username, but it always seems to involve accounts that were accidentally created or strictly administrative issues
11:22 < jmcarthur_work> i'm also envisioning things like social networking where a user might expect to be able to query uniquely for another user by username, but can't because that username doesn't necessarily identify the person they want
11:22 < mightybyte> It seems like this could be handled by just not allowing accounts to be deleted.
11:23 < mightybyte> Also, if you need that uniqueness, you could just make the username be an email address.
11:23 < jmcarthur_work> yeah
11:24 < jmcarthur_work> regardless, we should probably just have flexibility in happstack-auth, and developers can put tighter restrictions on a case by case basis
11:24 < mightybyte> Right
11:53 < jmcarthur_work> mightybyte, are there any other issues the you noticed in my changes so far?
11:53 < jmcarthur_work> *that you noticed
11:57 < jmcarthur_work> mightybyte, one thing i want to ask is about the prevalidation we discussed earlier. right now i just plan to expose one of the more primitive functions so the developer can wrap it with whatever validation code he wants himself. i find this preferable to a function that takes yet _another_ argument, but i want to know if you would rather have that than putting more requirements on the developer
12:00 < mightybyte> That makes sense to me.  Which lower-level function would we expose?
12:06 < mightybyte> I don't have any other issues right now.  But recently, my time has been spent on my app and I haven't had time to work on improving happstack-auth.
12:43 < jmcarthur_work> okay
12:45 < jmcarthur_work> the function names might not be entirely appropriate, but i'm thinking this one looks good: http://github.com/geezusfreeek/happstack-auth/blob/b0305a7b167715db15552ae41d4de9037b0eb63e/src/Happstack/Auth.hs#L238
12:46 < jmcarthur_work> that function isn't even a handler, in the server sense. definitely needs a rename i think
18:27 < tibbe> anyone feel like discussing a minimal http server api that supports chunk encoded streams?
21:43 < jmcarthur> mightybyte: i put up some (currently rather ugly) migration stuff, but it doesn't work properly. the sessions and users seem to be wiped out after the migration. i'm not really sure what to look for at this point
21:43 < jmcarthur> i haven't done migrations before now
22:24 < mightybyte> jmcarthur: I'm really busy right now.  I don't know when I'll have time to look at that, but I'll put it on my todo list.
22:26 < jmcarthur> mightybyte: that's fine. just letting you know what things are looking like. i will probably just move on to some of the other things i planned to do instead of worrying about the migration, yet
22:42 < mightybyte> jmcarthur: Ok, that's fine with me.  I don't have any migration experience either.
--- Log closed Wed May 27 00:00:22 2009