[01:22] blr: I've got three MPs up on https://code.launchpad.net/launchpad/+activereviews when you've stopped having fun with juju and mojo. [02:49] yes, "fun"... [02:49] will have a look [03:19] I am adjusting squid-forwardproxy atm. [03:25] wgrant: ah, what in particular? [03:28] blr: More flexible ACLs. [03:29] wgrant: are you touching auth_list? [03:29] blr: It is likely. [03:29] I'm trying to work out how to salvage it. [03:30] That doesn't go near your work, does it? [03:30] yeah, it isn't great by any means. [03:30] no that's fine, might need to update the mojo spec though. [03:31] wgrant: did you have a look at the auth_param changes btw? [03:31] blr: Ah, no, I didn't see an MP. [03:56] * wgrant scratches head [03:56] "This charm requires the following relation settings from clients: [03:56] ip: service ip address [03:56] port: service port [03:56] sitenames: space-delimited list of sites to whitelist [03:56] " [03:56] What possible use could the service port be to the proxy? [08:45] blr: https://code.launchpad.net/~wgrant/charms/precise/squid-forwardproxy/auth_list-deny/+merge/267626 [21:10] wgrant: looks like you've already merged it, sorry - certainly an improvement, particularly handling the inverse is nice. [21:13] wgrant: wrt to auth_param, without any special casing we would need a dict without nesting similar to {'scheme': 'basic', 'children': '0 startup=N idle=N'} etc. [21:16] was inclined to have all of the params mapped to keys, but probably just as clear that way [22:35] blr: I haven't merged it yet, and I realised a case last night that I'm not sure I can be bothered handling in a backward-compatible way, so it can probably wait for the more sensible redesign. [22:35] Specifically, there's no way to specify the order of ACL elements within an http_access line, which can be relevant when you're relying on short-circuiting for performance or to avoid unnecessary auth prompts. [23:49] wgrant: any thoughts on the auth_param stuff above? ^ will that suffice? [23:51] blr: Hm, perhaps have a special case that if the "children" key is a dict then it gets turned into a string? [23:53] So {"scheme": "basic", "children": "11", "utf8": "off"} and {"scheme": "basic", "children": {"number": 11}, "utf8": "off"} would be equivalent. [23:53] I suppose turning bools into strs would also make sense. [23:54] So you can still specify anything you want using strings, but there are also niceties for certain keys. [23:54] right [23:54] Does that make sense to you? [23:54] I think it's the least jarring approach. [23:55] yep, that seems reasonable