...
[14:09:26 CST(-0600)] <serac> We need to also keep in mind cases that are effectively warnings.
[14:09:49 CST(-0600)] <battags> well so currently warnings and actual exceptions are treated differently
[14:09:53 CST(-0600)] <serac> Where authentication succeeds but there is contextual information about authenticated state that needs to be caputred.
[14:09:57 CST(-0600)] <battags> they get triggered in two different parts of the CAS4 API
[14:10:09 CST(-0600)] <serac> Messages and Exceptions, right?
[14:10:21 CST(-0600)] <battags> someone read the API, woohoo!
[14:10:22 CST(-0600)] <battags> :-p
[14:10:32 CST(-0600)] <serac> I've definitely spent some time on it.
[14:10:45 CST(-0600)] <serac> Here we should probably be specific: warning and error.
[14:11:11 CST(-0600)] <serac> Warning is a case where auth succeeds but has information to present to user and error is failed auth that could be represented as exception.
[14:11:34 CST(-0600)] <serac> I'm really just advocating for calling it a warning in this case.
[14:11:50 CST(-0600)] <serac> Impending password expiration is a known use case.
[14:11:54 CST(-0600)] <serac> Dunno about others.
[14:12:19 CST(-0600)] <battags> that sounds fine
[14:12:30 CST(-0600)] <battags> I called it messages in the API because sometimes people display other crap
[14:12:43 CST(-0600)] <battags> not specific to the user
[14:13:53 CST(-0600)] <serac> Sure, so we could use the Message type here, but the method should be getWarnings() or similar.
[14:15:01 CST(-0600)] <serac> Big question: how pass warnings back from authentication handlers with existing api?
[14:15:12 CST(-0600)] <serac> Exceptions are pretty clear; warnings no so much.
[14:16:18 CST(-0600)] <battags> its why there was a generic API for messages because it seemed rather difficult to do it in the authenticationhandler
[14:16:31 CST(-0600)] <battags> though modifying existing APIs might get us in trouble 
[14:16:40 CST(-0600)] <serac> It will be a roadblock.
[14:16:59 CST(-0600)] <battags> I'd rather make sure we do this support right the first time
[14:17:05 CST(-0600)] <battags> even if it does mean modifying APIs
[14:17:10 CST(-0600)] <serac> I'm totally open.
[14:17:56 CST(-0600)] <serac> We should anticipate making a strong argument for this.
[14:18:00 CST(-0600)] <battags> this is where co-located design sessions would come in handy
[14:18:16 CST(-0600)] <serac> But folks want LPPE, so maybe we can use that as a concrete feature to justify some API changes.
[14:18:23 CST(-0600)] <battags> I'm trying to convince my wife we should install a really big whiteboard in the house
[14:18:34 CST(-0600)] <serac> I won that one for about 6 months.
[14:18:39 CST(-0600)] <serac> Then wife won.
[14:19:05 CST(-0600)] <battags> unfortunately her job doesn't require a whiteboard
[14:19:13 CST(-0600)] <serac> I can imagine.
[14:19:16 CST(-0600)] <serac> Can we continue later?
[14:19:24 CST(-0600)] <serac> Or another day? Time is up for me now.
[14:19:24 CST(-0600)] <battags> I'd have to counter-offer with like a CAT scan machine
[14:19:29 CST(-0600)] <serac> haha
[14:19:40 CST(-0600)] <battags> I'll be around sporadically on Saturday and Sunday
[14:19:42 CST(-0600)] <battags> more so on Sunday
[14:19:51 CST(-0600)] <battags> but if you IM me, I now have IRC on my phone
[14:19:57 CST(-0600)] <serac> Ok, sounds good.
[14:20:08 CST(-0600)] <battags> talk to you later! have a good weekend
[14:20:23 CST(-0600)] <serac> I'll try to hook up with you sometime. You too. Pax.