Available formats: content-negotiated html turtle (see SIOC for the vocabulary)
Back to channel and daily index: content-negotiated html turtle
These logs are provided as an experiment in indexing discussions using IRCHub.py, Irc2RDF.hs, and SIOC.
| 12:54:02 | <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 |
| 12:54:38 | <jmcarthur> | i got hung up on how to migrate an IxSet and ended up giving up yesterday |
| 14:23:16 | <mightybyte> | jmcarthur: I looked through some of your commits. I was wondering why you took out the UserId. |
| 14:24:01 | <jmcarthur_work> | i was going to ask you why it was there in the first place :) |
| 14:24:40 | <jmcarthur_work> | that was one of the major changes i meant to ask about |
| 14:25:03 | <jmcarthur_work> | would not be hard to put back if it must be there |
| 14:27:33 | <jmcarthur_work> | but yeah, my logic... usernames are unique anyway. no need for a separate id |
| 14:33:26 | <jmcarthur_work> | mightybyte, any thoughts? |
| 15:02:53 | <mightybyte> | jmcarthur_work: The idea was that it would allow users to change their username. |
| 15:03:46 | <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. |
| 15:05:39 | <jmcarthur_work> | the first reason didn't convince me, but i think the second one did |
| 15:06:33 | <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. |
| 15:08:08 | <mightybyte> | Also, removing it completely breaks my app. |
| 15:10:21 | <jmcarthur_work> | heh |
| 15:10:29 | <jmcarthur_work> | alright, i'll put it back |
| 15:11:08 | <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. |
| 15:11:20 | <jmcarthur_work> | i think you are right |
| 15:13:27 | <mightybyte> | It might also be good to throw in a comment explaining that it was an intenional design decision. |
| 15:13:45 | <jmcarthur_work> | yeah. prevent future occurrences of what i just did :) |
| 15:14:22 | <mightybyte> | Yep |
| 15:16:34 | <jmcarthur_work> | thinking about it... is it ever really a good idea to allow somebody to register with a username that was previously taken? |
| 15:18:02 | <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. |
| 15:18:33 | <jmcarthur_work> | not an argument against user ids, really, just thinking out loud |
| 15:18:41 | <mightybyte> | Yeah |
| 15:19:06 | <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 |
| 15:19:17 | <mightybyte> | Although it seems like a fairly conservative policy. |
| 15:19:34 | <mightybyte> | s/Although// |
| 15:20:40 | <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 |
| 15:22:00 | <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 |
| 15:22:38 | <mightybyte> | It seems like this could be handled by just not allowing accounts to be deleted. |
| 15:23:09 | <mightybyte> | Also, if you need that uniqueness, you could just make the username be an email address. |
| 15:23:34 | <jmcarthur_work> | yeah |
| 15:24:12 | <jmcarthur_work> | regardless, we should probably just have flexibility in happstack-auth, and developers can put tighter restrictions on a case by case basis |
| 15:24:21 | <mightybyte> | Right |
| 15:53:34 | <jmcarthur_work> | mightybyte, are there any other issues the you noticed in my changes so far? |
| 15:53:44 | <jmcarthur_work> | *that you noticed |
| 15:57:32 | <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 |
| 16:00:19 | <mightybyte> | That makes sense to me. Which lower-level function would we expose? |
| 16:06:40 | <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. |
| 16:43:48 | <jmcarthur_work> | okay |
| 16:45:36 | <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 |
| 16:46:49 | <jmcarthur_work> | that function isn't even a handler, in the server sense. definitely needs a rename i think |
| 22:27:11 | <tibbe> | anyone feel like discussing a minimal http server api that supports chunk encoded streams? |
Back to channel and daily index: content-negotiated html turtle