jasig-cas IRC Logs-2011-07-22

Owned by Apereo Infrastructure
Last updated: Jul 22, 2011Version comment
26 min read

[07:57:42 CDT(-0500)] <fairwinds> hi. hoping someone can answer a couple of basic questions about cas
[07:59:04 CDT(-0500)] <fairwinds> I have a front end app that folks must currently authenticate against to access their account/profile etc
[08:01:56 CDT(-0500)] <fairwinds> and I am setting up so that there are links to various apps. I would like for a user signed into this app to be able to click links to the apps an be signed in when they do.
[08:09:43 CDT(-0500)] <fairwinds> I want user to login to be able to login to first app (account app) and eliminate need for multiple prompts when the user switches from one application to the next when they click links to access each app within this app
[12:55:25 CDT(-0500)] <apetro> I tried to set the Topic of this channel to document that the designated weekly discussion time is 2pm to 3pm Eastern (to help guide folks coming to the channel at other times and noting quite as was noted today on cas-user) but I'm not a Channel Operator so apparently I can't set the Topic.
[12:55:32 CDT(-0500)] * apetro despises IRC
[12:56:43 CDT(-0500)] <serac> Good idea. I was at one time a channel op, but it got fubared somehow.
[12:57:12 CDT(-0500)] <MarvinAddison> battags can do it when he shows up
[12:57:47 CDT(-0500)] <apetro> how do accounts get "blessed" as operators?
[12:58:16 CDT(-0500)] <MarvinAddison> I forget. Eric was involved iirc.
[12:58:32 CDT(-0500)] <apetro> k
[12:59:21 CDT(-0500)] <apetro> I think Unicon has a resource to put on this manual contribution task: https://issues.jasig.org/browse/CAS-1010
[12:59:26 CDT(-0500)] <apetro> How's the manual effort looking otherwise?
[12:59:39 CDT(-0500)] <MarvinAddison> No movement here.
[12:59:52 CDT(-0500)] <MarvinAddison> I should be able to donate cycles early next week.
[12:59:54 CDT(-0500)] <apetro> k.
[13:00:11 CDT(-0500)] <apetro> I'd like to get to completion on where manual efforts can be tracked in JIRA
[13:00:27 CDT(-0500)] <wgthom> checkin in
[13:00:29 CDT(-0500)] <MarvinAddison> A noble goal.
[13:00:35 CDT(-0500)] <MarvinAddison> And doable, just need to hunker down.
[13:00:38 CDT(-0500)] <MarvinAddison> Hey wgthom.
[13:00:48 CDT(-0500)] <apetro> it's a pedantic thing, but internally to Unicon my life is easier if I can articulate what JIRA issue an effort is pursuing.
[13:01:03 CDT(-0500)] <apetro> hey wgthom
[13:01:10 CDT(-0500)] <MarvinAddison> It helps me track progress as well.
[13:01:19 CDT(-0500)] <apetro> I'm sneaking in some agenda bash / mopup of pedantic stuff in advance of the discussion (smile)
[13:01:31 CDT(-0500)] <apetro> welcome battags
[13:01:36 CDT(-0500)] <MarvinAddison> Howdy battags.
[13:01:36 CDT(-0500)] <battags> hello!
[13:01:55 CDT(-0500)] <battags> code is compiling so I have some free time :-D
[13:01:57 CDT(-0500)] <MarvinAddison> Any more little stuff before fit hits the shan?
[13:02:41 CDT(-0500)] <MarvinAddison> Silence means no.
[13:02:41 CDT(-0500)] <wgthom> sup scott
[13:02:53 CDT(-0500)] <MarvinAddison> So the big thing to hash out today is roadmap.
[13:03:07 CDT(-0500)] <apetro> agreed
[13:03:17 CDT(-0500)] <MarvinAddison> I had intended to distill some talking points, but it turned out harder than I'd thought when I reviewed the massive threads on cas-steering.
[13:03:53 CDT(-0500)] <apetro> perhaps everyone is in cacophonous agreement?
[13:03:57 CDT(-0500)] <MarvinAddison> I'd like to steer the discussion a little in any case so we're prodive.
[13:04:03 CDT(-0500)] <MarvinAddison> Doubtful apetro.
[13:04:09 CDT(-0500)] <wgthom> not sure iirc has enough bandwidth for this conversation
[13:04:10 CDT(-0500)] <MarvinAddison> s/prodive/productive/
[13:04:14 CDT(-0500)] <MarvinAddison> Maybe not.
[13:04:15 CDT(-0500)] <apetro> the threads seemed to distill down to "We prefer an evolutionary approach"
[13:04:18 CDT(-0500)] <MarvinAddison> But we need to talk.
[13:04:31 CDT(-0500)] <MarvinAddison> I absolutely do not think we're all there apetro.
[13:04:37 CDT(-0500)] <apetro> alright
[13:04:39 CDT(-0500)] <wgthom> how about agenda bash first?
[13:04:39 CDT(-0500)] <apetro> I had to try (smile)
[13:04:44 CDT(-0500)] <MarvinAddison> But that's one bottom line point we need to discuss.
[13:04:53 CDT(-0500)] <MarvinAddison> I'm personally warming up to it.
[13:04:58 CDT(-0500)] <MarvinAddison> But devil is in details.
[13:04:58 CDT(-0500)] <apetro> certainly we're not there as regards the bigger strategic vision, CAS-and-Shib, etc. There's some horizon on which I'll agree we're not there.
[13:05:34 CDT(-0500)] <MarvinAddison> Honestly I think we'd be well served by leaving Shib out of the discussion for the present.
[13:05:38 CDT(-0500)] <MarvinAddison> It's relevant for sure.
[13:05:46 CDT(-0500)] <MarvinAddison> But it needless complicates matters.
[13:05:54 CDT(-0500)] <MarvinAddison> I think we're fairly divergent on Shib integration.
[13:06:04 CDT(-0500)] <MarvinAddison> So here's a question:
[13:06:10 CDT(-0500)] <wgthom> short term, i'm keen on just cleaning up the roadmap docs as they stand and getting them into some coherent form
[13:06:50 CDT(-0500)] <MarvinAddison> We've been thrashing on the versions and the vision a bit over the past 2 years.
[13:06:56 CDT(-0500)] <apetro> total agreement with wgthom 's keenness and with MarvinAddison 's point that there's an important discussion to be had short of considering the bigger strategy
[13:07:08 CDT(-0500)] <MarvinAddison> If we're going to really think about roadmap, it should be what we really intend to do.
[13:07:15 CDT(-0500)] <apetro> indeed
[13:07:28 CDT(-0500)] <MarvinAddison> So can we evolve 3.x into 4?
[13:07:35 CDT(-0500)] <MarvinAddison> Sure we can.
[13:07:51 CDT(-0500)] <MarvinAddison> But that just begs the question of what's in 4.
[13:08:05 CDT(-0500)] <MarvinAddison> I believe we must design for multiprotocol support.
[13:08:13 CDT(-0500)] <apetro> most tactically, can we evolve 3.x into 3.5? yes we can. And we should. and there's near term good stuff that "wants" to evolve in there.
[13:08:16 CDT(-0500)] <MarvinAddison> That should be the endpoint.
[13:08:21 CDT(-0500)] <wgthom> may be helpful to distinguish roadmap (near term, achievable, sustainable, community needs driven) from big vision.
[13:08:29 CDT(-0500)] <battags> there's a roadmap that had that on it
[13:08:39 CDT(-0500)] <MarvinAddison> Need to cite links here.
[13:09:37 CDT(-0500)] <wgthom> i think of roadmap as the thing I want to base my local campus plans on
[13:10:02 CDT(-0500)] <MarvinAddison> I don't think of it that way at all.
[13:10:07 CDT(-0500)] <MarvinAddison> Maybe that's part of the problem.
[13:10:16 CDT(-0500)] <MarvinAddison> I see it as an actionable plan by the devs.
[13:10:33 CDT(-0500)] <wgthom> that too...
[13:11:03 CDT(-0500)] <MarvinAddison> Any plan that isn't actionable is a strategic failure is my point I guess.
[13:11:16 CDT(-0500)] <wgthom> agreed.
[13:11:28 CDT(-0500)] <wgthom> 100%
[13:12:12 CDT(-0500)] <MarvinAddison> Core API support for multi-protocol is a core ideal of the next big version, whatever its number.
[13:12:15 CDT(-0500)] <wgthom> i'm not saying that the current CAS Roadmap(s) have this quality…I'm saying I beleive they should
[13:12:28 CDT(-0500)] <MarvinAddison> Do we have agreement we should pursue that?
[13:12:34 CDT(-0500)] <MarvinAddison> (we're doomed if we don't)
[13:13:20 CDT(-0500)] <apetro> hmm. Not sure I agree disagreement about what big new features should be in the next big new version of CAS spells doom.
[13:13:38 CDT(-0500)] <MarvinAddison> Here's how we're doomed:
[13:13:49 CDT(-0500)] <MarvinAddison> - We've publicly stated it will have this.
[13:13:59 CDT(-0500)] <MarvinAddison> - We've spent a lot of design and impl time on it already
[13:13:59 CDT(-0500)] <wgthom> I think we should narrow the context for 3.x roadmap to (achievable, sustainable, near term,…) and kick up the bigger strategic question for more input
[13:14:31 CDT(-0500)] <wgthom> I don' think we can answer the Core API question right now
[13:14:31 CDT(-0500)] <fairwinds> Hi. I am new to CAS so apologize if questions seem a bit lame. Have been reading guide for advice thus far. I make good use of CouchDB and am keen to do a few things with it. 1) create a CAS auth handler to authenticate users 2) use CouchDB as a ticket registry and 3) create an authentication plugin in erlang for CouchDB to direct auth to CAS through its javascript interface. I am going to start with authentication handler to use the _user
[13:14:32 CDT(-0500)] <fairwinds> as source or user/password.
[13:14:33 CDT(-0500)] <MarvinAddison> The thing is that we've been stating this point in public for over two years now and there has never been any disagreement.
[13:15:07 CDT(-0500)] <MarvinAddison> fairwinds – need to hold of on that discussion for a bit
[13:15:10 CDT(-0500)] <apetro> fairwinds , excellent question, and one I expect we'd all like to discuss with you, but can we defer it to outside this hour, our weekly cas-dev discussion?
[13:15:39 CDT(-0500)] <MarvinAddison> Everyone is here who really has a development stake in the design.
[13:15:45 CDT(-0500)] <MarvinAddison> Why would we put it off any further?
[13:16:14 CDT(-0500)] <MarvinAddison> Everyone who had a stakehold otherwise has had ample time to provide feedback at conferences, on the list, etec.
[13:16:16 CDT(-0500)] <MarvinAddison> etc
[13:16:18 CDT(-0500)] <fairwinds> k, sorry will come back in an hour or so
[13:16:23 CDT(-0500)] <MarvinAddison> later
[13:16:51 CDT(-0500)] <apetro> (just to be clear I'm not trying to be ornery or obstructionist: I don't oppose multi-protocol. I think it's a fine idea, an attractive set of features. I'm also open to discovering other major features that need to be in a revolutionary new CAS version.)
[13:17:07 CDT(-0500)] <MarvinAddison> Sure, but we need to act now.
[13:17:39 CDT(-0500)] <MarvinAddison> We've been talking way too long about CAS 4 – we need to show something that resembles the roadmaps we've publicly disclosed.
[13:17:54 CDT(-0500)] <MarvinAddison> It's starting to feel like vaporware.
[13:18:50 CDT(-0500)] <wgthom> I've seen this before…. up2/3
[13:19:10 CDT(-0500)] <MarvinAddison> I'm happy to learn from out past mistakes so we don't repeat them.
[13:19:35 CDT(-0500)] <MarvinAddison> But waiting for more community input about what CAS should be is a strategic misstep.
[13:19:42 CDT(-0500)] <wgthom> well, one thing is not to fear revisiting the roadmap/strategy/etc.
[13:19:49 CDT(-0500)] <MarvinAddison> And here we are.
[13:19:50 CDT(-0500)] <wgthom> agreed
[13:20:14 CDT(-0500)] <wgthom> i wouldn't wait for feedback…I'm might actively solocit it
[13:20:38 CDT(-0500)] <MarvinAddison> I'm ok with that as long as we don't block on active progress toward goals we presently agree on.
[13:21:15 CDT(-0500)] <MarvinAddison> Part of the problem is that CAS4 largely already exists.
[13:21:23 CDT(-0500)] <MarvinAddison> So it is what it is.
[13:21:31 CDT(-0500)] <wgthom> clean up roadmap(s), move cas4 to git, move cas3 back to truck, work on getting a 3.5 out this calendar year
[13:22:04 CDT(-0500)] <MarvinAddison> What about all the work that's already gone into 4?
[13:22:06 CDT(-0500)] <MarvinAddison> ??
[13:22:21 CDT(-0500)] <MarvinAddison> I have a feeling we're considering scrapping it, which would be a mistake.
[13:22:42 CDT(-0500)] <wgthom> back to the up2/3 scenario…. (smile)
[13:22:49 CDT(-0500)] <wgthom> don't scrap it.
[13:23:19 CDT(-0500)] <wgthom> if there's goodness there that can be taking up consistent with the release strategy for 3.x, then do it.
[13:23:51 CDT(-0500)] <MarvinAddison> That's a pretty severe condition to meet.
[13:24:03 CDT(-0500)] <wgthom> if folks are interested in continuing the revolutionary multi-protocol design while the strategic vision is taking shape, they can.
[13:24:14 CDT(-0500)] <MarvinAddison> Let me propose something:
[13:24:23 CDT(-0500)] <MarvinAddison> multi-protocol isn't necessarily revolutionary.
[13:24:43 CDT(-0500)] <MarvinAddison> It could potentially be derived from current 3.x branch.
[13:24:51 CDT(-0500)] <apetro> how is this a high bar? being worth pursuing in parallel with the continued evolution of the presently released codebase has always been the bar a revolutionary new development effort and release has to meet?
[13:24:52 CDT(-0500)] <MarvinAddison> Does that make us feel any warmer about it?
[13:25:12 CDT(-0500)] <MarvinAddison> It's a high bar because it puts pre-eminence on the current version.
[13:25:25 CDT(-0500)] <wgthom> indeed.
[13:25:26 CDT(-0500)] <MarvinAddison> There are some things about its design that are fundamentally limiting.
[13:25:48 CDT(-0500)] <apetro> which fundamental limitations create the opportunity for a revolutionary new version to gain traction,
[13:26:18 CDT(-0500)] <wgthom> scott, tracking?
[13:26:19 CDT(-0500)] <MarvinAddison> I think many of us have already recognized them.
[13:26:44 CDT(-0500)] <MarvinAddison> And thus the support for the roadmap as stated in the past that lists api redesign for multi-proto as a goal.
[13:27:24 CDT(-0500)] <MarvinAddison> I'm just curious why we're reconsidering this now?
[13:28:18 CDT(-0500)] <apetro> I'll stipulate that I've been terribly remiss in not considering it better earlier and getting on top of this sooner, if that helps any.
[13:28:37 CDT(-0500)] <battags> is there a reason not to do multi-protocol?
[13:28:42 CDT(-0500)] <apetro> tactically, freezing of evolutionary work on cas3 has begun to cause pain
[13:28:55 CDT(-0500)] <apetro> enough pain to create pressure to resolve this and allow further evolutionary cas3 releases.
[13:28:57 CDT(-0500)] <MarvinAddison> That's such a low level issue.
[13:29:00 CDT(-0500)] <battags> the committee decided not to do evolutionary work
[13:29:01 CDT(-0500)] <MarvinAddison> It could be resolved today.
[13:29:10 CDT(-0500)] <MarvinAddison> At least as I understand your concern.
[13:29:12 CDT(-0500)] <battags> there was this road map that was scrapped: https://wiki.jasig.org/pages/viewpage.action?pageId=28574039
[13:29:27 CDT(-0500)] <MarvinAddison> It's just svn work really, unless you mean something else.
[13:30:00 CDT(-0500)] <MarvinAddison> Not really seeing the block in 3.x releases either.
[13:30:04 CDT(-0500)] <MarvinAddison> 3.4.9 is imminent.
[13:30:26 CDT(-0500)] <MarvinAddison> Let's be specific. What's being blocked? What can we do to unblock?
[13:30:35 CDT(-0500)] <apetro> https://wiki.jasig.org/display/~awp9/Andrew+Personal+Vision+for+CAS+Roadmap
[13:31:36 CDT(-0500)] <MarvinAddison> At least multi-protocol is on there (smile)
[13:31:41 CDT(-0500)] <battags> lol
[13:31:42 CDT(-0500)] <apetro> specifically, this needs to be a copy of 3.4.x marching towards 3.5: https://source.jasig.org/cas3/trunk/ . What we can do to unblock is svn cp trunk to a development branch, or decide to pursue cas 3.5 in a branch I suppose.
[13:32:13 CDT(-0500)] <MarvinAddison> I want to reiterate that we may be able to evolve 3.x into multiprotocol more gently.
[13:32:35 CDT(-0500)] <apetro> indeed. I don't oppose multi-protocol. I don't oppose a revolutionary new cas. I'm getting increasingly passionate about a cas 3.5 release addressing some of the missing features and operational pains that I'm tripping over in support and consulting.
[13:32:44 CDT(-0500)] <MarvinAddison> No argument there.
[13:32:52 CDT(-0500)] <MarvinAddison> Can we agree today to do the svn work you just mentioned?
[13:33:06 CDT(-0500)] <wgthom> thought we already agreed to that.
[13:33:18 CDT(-0500)] <wgthom> +1 for cas3.x on the trunk, and cas4 on git
[13:33:22 CDT(-0500)] <battags> let's be clear also: we're in this position because we as a steering committee haven't been able to recruit additional developers
[13:33:25 CDT(-0500)] <apetro> and I absolutely want to lead with I don't get to personally dictate CAS features. Grouper integration and coarse grained access control, possibly a bad idea. But it came up a couple times recently, so it's time to start kicking the idea around and having a place to offer it and see where it goes.
[13:33:51 CDT(-0500)] <MarvinAddison> We have a use case for fine-grained access control. It's perfectly reasonable.
[13:33:54 CDT(-0500)] <wgthom> +1 for considering cas3.x on git too. (smile)
[13:34:43 CDT(-0500)] <MarvinAddison> Please review https://issues.jasig.org/browse/CAS-997
[13:35:13 CDT(-0500)] <wgthom> yep
[13:35:14 CDT(-0500)] <MarvinAddison> battags – on the point of devs, I'm expecting Andrew or Unicon or somebody to contribute the things he mentioned.
[13:35:48 CDT(-0500)] <MarvinAddison> I would imagine we'd likely have a shepherding role if any. Correct me apetro if that's offbase.
[13:36:01 CDT(-0500)] <apetro> that's roughly right
[13:36:08 CDT(-0500)] <battags> yes I'm not concerned about Cooperative Support
[13:36:09 CDT(-0500)] <apetro> my personal track record on finding extra time to put on cas development is bad
[13:36:16 CDT(-0500)] <MarvinAddison> haha
[13:36:19 CDT(-0500)] <battags> but what I
[13:36:41 CDT(-0500)] <battags> but what I'm saying is that Andrew's statement about him needing a 3.5 is partially our doing in not being able to get resources to get 4.0 out when we said we would
[13:36:45 CDT(-0500)] <apetro> Unicon's is actually pretty good. Cooperative Support has development bandwidth. It's most in keeping with the spirit of the program to use that for maintenance and evolution.
[13:37:18 CDT(-0500)] <wgthom> battags, back to up2/3 story again
[13:37:38 CDT(-0500)] <battags> up2/3 had resources
[13:37:45 CDT(-0500)] <battags> I'm not sure what that has to do with anything
[13:37:55 CDT(-0500)] <apetro> Some of the features I cite are features Unicon's already done at adopters. The only thing blocking post a patch for the per-service-username feature is me finding time, e.g. That's a fine example of a feature that doesn't belong in 3.4 and doesn't require 4. Modest, high-value enhancement.
[13:38:28 CDT(-0500)] <battags> Andrew but my point was that in theory you should have been developing it for 4, because it should have been out already (smile)
[13:38:37 CDT(-0500)] <MarvinAddison> fair enough
[13:38:44 CDT(-0500)] <apetro> battags, I don't share that vision
[13:38:51 CDT(-0500)] <apetro> and I guess that needs discussed
[13:38:56 CDT(-0500)] <wgthom> who's going to be the first CAS 4 deployer? anyone in the hopper?
[13:38:59 CDT(-0500)] <apetro> specifically, even if CAS 4 were released today
[13:39:00 CDT(-0500)] <MarvinAddison> A year ago you didn't think 4 would be out?
[13:39:06 CDT(-0500)] <MarvinAddison> We will.
[13:39:13 CDT(-0500)] <apetro> I'd still want to be talking about an evolutionary 3.5 release.
[13:39:14 CDT(-0500)] <MarvinAddison> I'm a strong believer in eating my own dog food.
[13:39:40 CDT(-0500)] <battags> if I still worked for RU we would be (wink)
[13:39:49 CDT(-0500)] <battags> they'd probably migrate anyway even without me there
[13:39:51 CDT(-0500)] <wgthom> OK. so let's cut to the chase. free up 3.x line and get 4.x out on it's own… the community will come to it based on it's merits
[13:39:52 CDT(-0500)] <MarvinAddison> That's actually a good question, though.
[13:40:00 CDT(-0500)] <MarvinAddison> We should be trying to get folks to stay on the upgrade curve.
[13:40:15 CDT(-0500)] <wgthom> if VT gets it into production that will be stong indication for folks to migrate
[13:40:23 CDT(-0500)] <wgthom> in the mean time, let's continue to evovle 3.x
[13:40:29 CDT(-0500)] <MarvinAddison> Sure. Just need a handful of success storeies.
[13:40:35 CDT(-0500)] <battags> here's the reality though: what's our bandwidth to continue developing both branches simultaneously?
[13:41:09 CDT(-0500)] <apetro> right. What I'd like to work towards in a 3.5 release is something that allows the adopters I've worked with to keep up with the upgrade curve, in that it has the features that they've locally needed and sometimes locally implemented.
[13:42:14 CDT(-0500)] <MarvinAddison> I have concerns about maintaining two branches.
[13:42:23 CDT(-0500)] <apetro> dunno. I'm not prepared to offer significant resources towards cas4
[13:42:29 CDT(-0500)] <wgthom> we probably need two maintaners
[13:42:35 CDT(-0500)] <wgthom> one for 4.x and one for 3.x
[13:42:50 CDT(-0500)] <MarvinAddison> Pretty unfair to call the person on 4.x a maintainer.
[13:43:00 CDT(-0500)] <MarvinAddison> There's a lot of design/build/test work.
[13:43:07 CDT(-0500)] <apetro> I am prepared to point Coop Dev CAS towards maintenance efforts and to (continue to) encourage Unicon CAS customization projects to yield progress in the open source software product.
[13:43:11 CDT(-0500)] <MarvinAddison> The stuff on Andrew's roadmap looks like boilerplat maint work.
[13:43:14 CDT(-0500)] <MarvinAddison> For 3.x
[13:43:23 CDT(-0500)] <wgthom> no dispersion meant re "maintianer"
[13:43:32 CDT(-0500)] <MarvinAddison> Sure, just wanted to clarify.
[13:43:36 CDT(-0500)] <battags> the stuff on Andrew's roadmap still needs to make it into 4
[13:43:36 CDT(-0500)] <wgthom> what i meant is someone in charge of shepparding the releases independantly
[13:43:41 CDT(-0500)] <wgthom> i have iirc by the way
[13:43:48 CDT(-0500)] <wgthom> for this type of converstation
[13:44:21 CDT(-0500)] <wgthom> hate….that is
[13:44:32 CDT(-0500)] <battags> so maybe the thing is to take a step back first and actually determine what we have the resources/bandwidth for
[13:44:33 CDT(-0500)] <MarvinAddison> The 4.x "maintainer" would be responsible for merging in 3.x features in my view.
[13:44:49 CDT(-0500)] <wgthom> could be...
[13:45:03 CDT(-0500)] <battags> then there needs to be agreement from all commiters that it should have been in 3.x
[13:45:26 CDT(-0500)] <wgthom> what should have been in 3.x?
[13:45:34 CDT(-0500)] <battags> we need to make sure this doesn't become the 3.x team and the 4.0 team
[13:45:41 CDT(-0500)] <apetro> in general we look for consensus among committers about changes in the code, yes?
[13:45:43 CDT(-0500)] <MarvinAddison> Meant merging a 3.x feature into 4.x. Hopefully that's not controversial – if it's valuable for 3.x should be true of 4.x.
[13:45:53 CDT(-0500)] <wgthom> ture
[13:45:55 CDT(-0500)] <wgthom> true
[13:46:10 CDT(-0500)] <wgthom> reverse should be true as well.
[13:46:16 CDT(-0500)] <battags> assuming its one team I am in agreement
[13:46:19 CDT(-0500)] <MarvinAddison> But possibly more controlversial.
[13:46:24 CDT(-0500)] <battags> my concern becomes if the teams aren't talking (smile)
[13:46:29 CDT(-0500)] <battags> not because they don't like each other
[13:46:38 CDT(-0500)] <MarvinAddison> Yeah, avoid like the plague.
[13:46:39 CDT(-0500)] <battags> but just because they're each doing their own thing
[13:46:43 CDT(-0500)] <MarvinAddison> Must be one team and collaborate.
[13:46:51 CDT(-0500)] <wgthom> agreed
[13:46:56 CDT(-0500)] <MarvinAddison> With different scopes is how I'm seeing it.
[13:47:16 CDT(-0500)] <wgthom> yes, one product
[13:47:19 CDT(-0500)] <wgthom> not two projects
[13:47:56 CDT(-0500)] <battags> what I don't want is for someone to upgrade to 4 and find out something is different/not done in CAS4
[13:48:05 CDT(-0500)] <battags> and that both including and not including it were valid decisions (wink)
[13:48:34 CDT(-0500)] <MarvinAddison> I'd imagine we'd just have to tackle those on case-by-case basis.
[13:48:40 CDT(-0500)] <wgthom> CAS4 should strive for feature comparity with CAS3
[13:48:57 CDT(-0500)] <wgthom> starts to sound like apache1/2 story
[13:49:10 CDT(-0500)] <battags> you're potentially putting a burden on the CAS4 team
[13:49:13 CDT(-0500)] <MarvinAddison> That's reassuring – Apache 2.x is awesome.
[13:49:17 CDT(-0500)] <wgthom> lol
[13:49:17 CDT(-0500)] <battags> and I'm going to pick on a feature
[13:49:20 CDT(-0500)] <battags> apologies to the Grouper people
[13:49:29 CDT(-0500)] <battags> but Andrew's roadmap has Grouper integration
[13:49:32 CDT(-0500)] <battags> if that makes it into 3.x
[13:49:43 CDT(-0500)] <battags> now its my responsibility on how to put it in CAS4?
[13:49:46 CDT(-0500)] <battags> assuming I am working on CAS4
[13:49:50 CDT(-0500)] <battags> and its not vice versa (smile)
[13:49:58 CDT(-0500)] <battags> maybe I'll stick to CAS3 and let Andrew have CAS4 (wink)
[13:50:04 CDT(-0500)] <MarvinAddison> haha
[13:50:31 CDT(-0500)] <MarvinAddison> Maybe this becomes less of a burden if we could evolve into some of the CAS4 features from the 3.x codebase?
[13:50:37 CDT(-0500)] <apetro> sure. You're welcome to stick with cas3. If no one's motivated to work on cas4, then it's not yet time for the revolutionary new version. (smile)
[13:50:41 CDT(-0500)] <wgthom> well, again…I think there's space to stake a step back regarding the strategic vision…
[13:50:56 CDT(-0500)] <battags> again its why we had a road map with 3.5 - 4.0 in it
[13:51:12 CDT(-0500)] <battags> I'm not saying the roadmap is 100% perfect
[13:51:20 CDT(-0500)] <battags> but can we start with something like that
[13:51:26 CDT(-0500)] <battags> its looks similar in concept to Andrew's vision
[13:51:34 CDT(-0500)] <battags> though since there are some API changes it might require re-numbering
[13:51:40 CDT(-0500)] <battags> to the Chrome method
[13:51:48 CDT(-0500)] <battags> of going from 1 to 13 in like a month
[13:51:56 CDT(-0500)] <MarvinAddison> Version numbers be damned.
[13:52:01 CDT(-0500)] <apetro> eh
[13:52:08 CDT(-0500)] <MarvinAddison> Do the meaningful work and then figure out what to call it.
[13:52:16 CDT(-0500)] <apetro> I'm not sure I buy that most of this requires or benefits from a bunch of API changes
[13:52:20 CDT(-0500)] <MarvinAddison> Just be honest about the scope of changes.
[13:52:41 CDT(-0500)] <MarvinAddison> I don't see any API changes necessarily until 4.0 on your roadmap.
[13:53:06 CDT(-0500)] <apetro> adding coarse-grained access control isn't an API change so much as additional data in the services registry, model of services, e.g. Certainly a version rev (schema changed), but no big change.
[13:53:09 CDT(-0500)] <MarvinAddison> And that's when it gets really hard if we go with a clean-room approach to API changes.
[13:55:14 CDT(-0500)] <MarvinAddison> Can someone cite the current roadmap doc?
[13:55:28 CDT(-0500)] <apetro> indeed. We have something better than the one I made up today, right? (smile)
[13:55:50 CDT(-0500)] <battags> the link I keep pasting
[13:55:57 CDT(-0500)] <wgthom> https://issues.jasig.org/browse/CASST-7
[13:55:59 CDT(-0500)] <apetro> https://issues.jasig.org/browse/CASST-7
[13:56:17 CDT(-0500)] <wgthom> specifically the comments....
[13:57:33 CDT(-0500)] <apetro> so, we're taking this one and evolving it to the current vision? https://wiki.jasig.org/pages/viewpage.action?pageId=28574039 ?
[13:57:48 CDT(-0500)] <MarvinAddison> That's the one I'm thinking of.
[13:57:56 CDT(-0500)] <apetro> and, like, deleting all its competitors
[13:57:57 CDT(-0500)] <apetro> ?
[13:58:12 CDT(-0500)] <wgthom> or at least linking them all to the one true path
[13:58:17 CDT(-0500)] <MarvinAddison> +1 for using that one as a starting point.
[13:58:31 CDT(-0500)] <wgthom> i'm happy to own the confluence clean up
[13:58:45 CDT(-0500)] <battags> I fixed a couple of them to point to that doc
[13:58:46 CDT(-0500)] <wgthom> how does one update the website one?
[13:58:48 CDT(-0500)] <battags> mostly the web site
[13:58:54 CDT(-0500)] <battags> I changed the web site a while back
[13:59:00 CDT(-0500)] <battags> its in the email thread I believe
[13:59:01 CDT(-0500)] <wgthom> http://www.jasig.org/cas/roadmap
[13:59:02 CDT(-0500)] <MarvinAddison> I think the JMX control points could be a very nice compartmentalized feature for a 3.x version.
[13:59:12 CDT(-0500)] <wgthom> ah...good
[13:59:21 CDT(-0500)] <battags> so the thing with some of these
[13:59:27 CDT(-0500)] <battags> and why we delayed them
[13:59:28 CDT(-0500)] <battags> if you do it for 3.x APIs
[13:59:30 CDT(-0500)] <MarvinAddison> Lots of good stuff in that roadmap.
[13:59:35 CDT(-0500)] <battags> then we need to do it again for the 4.x APIs
[13:59:49 CDT(-0500)] <battags> well I shouldn't say 4.x, I should say the changed APIs
[13:59:53 CDT(-0500)] <battags> whenever they get implemented
[13:59:57 CDT(-0500)] <wgthom> one things we can do is get all the ideas off the "roadmap" and into a great ideas list.
[14:00:25 CDT(-0500)] <battags> so the ideas list would be the vision and roadmap document (smile)
[14:00:26 CDT(-0500)] <wgthom> then be more conservative with the roadmap, and talk about what is actually being worked on
[14:00:32 CDT(-0500)] <wgthom> something like that
[14:00:55 CDT(-0500)] <MarvinAddison> All these feature ideas shouldn't get lost for sure.
[14:01:02 CDT(-0500)] <wgthom> agreed...
[14:01:07 CDT(-0500)] <battags> so if its just what we're currently working on, that's JIRA (wink)(
[14:01:32 CDT(-0500)] <wgthom> sort of…roadmap for more distilled that jira issues
[14:01:37 CDT(-0500)] <wgthom> is more distilled.
[14:01:42 CDT(-0500)] <wgthom> more acceidble
[14:01:44 CDT(-0500)] <wgthom> accessible
[14:01:50 CDT(-0500)] <wgthom> for none devs
[14:01:55 CDT(-0500)] <wgthom> non-devs
[14:02:02 CDT(-0500)] <MarvinAddison> Dude, you're having a time.
[14:02:04 CDT(-0500)] <battags> Bill, just quit typing :-p
[14:02:06 CDT(-0500)] <wgthom> lol
[14:02:15 CDT(-0500)] <battags> thank god you use autocomplete in Eclipse?
[14:02:27 CDT(-0500)] <wgthom> ugh…my time is up…i thank you for yours.
[14:02:33 CDT(-0500)] <MarvinAddison> sure, later
[14:02:38 CDT(-0500)] <apetro> so before we tie this off
[14:02:40 CDT(-0500)] <apetro> tactically
[14:02:42 CDT(-0500)] <battags> see you next week!
[14:02:47 CDT(-0500)] <apetro> https://issues.jasig.org/browse/CAS-997 is assigned to you, battags
[14:02:50 CDT(-0500)] <battags> Bill owns all things roadmap since he left (wink)
[14:02:53 CDT(-0500)] <apetro> timeline on execution on that?
[14:02:54 CDT(-0500)] <MarvinAddison> haha
[14:03:01 CDT(-0500)] <battags> its after 3.4.9
[14:03:17 CDT(-0500)] <MarvinAddison> I committed to doing pre-release review today.
[14:03:21 CDT(-0500)] <MarvinAddison> Should be able to get to that.
[14:03:30 CDT(-0500)] <MarvinAddison> Then 3.4.9 get get out the door and we can get moving.
[14:04:03 CDT(-0500)] <apetro> cool
[14:04:51 CDT(-0500)] <battags> ideally let's get the roadmap hashed out before we start moving stuff
[14:04:53 CDT(-0500)] <battags> (smile)
[14:04:56 CDT(-0500)] <MarvinAddison> I'd recommend watching https://wiki.jasig.org/pages/viewpage.action?pageId=28574039.
[14:05:06 CDT(-0500)] <MarvinAddison> So we can all comment on changes if needed.
[14:05:35 CDT(-0500)] <battags> btw one thing on that roadmap is changing to Apache2 license
[14:05:39 CDT(-0500)] <battags> we need to do that at some point
[14:06:13 CDT(-0500)] <MarvinAddison> Let's do it for whatever becomes the next minor release, e.g. 3.5.
[14:06:26 CDT(-0500)] <battags> that's what the roadmap says :-p
[14:06:32 CDT(-0500)] <MarvinAddison> Yeah, thank God.
[14:06:42 CDT(-0500)] <apetro> wait, we haven't done that yet?
[14:06:43 CDT(-0500)] <MarvinAddison> At least one thing remains the same (smile)
[14:06:54 CDT(-0500)] <MarvinAddison> no
[14:07:03 CDT(-0500)] <apetro> ok, that's another reason to do an evolutionary cas 3.5 release pronto (smile)
[14:07:44 CDT(-0500)] <battags> in its defense its been on the roadmap as a 3.5 task for a while (wink)
[14:07:58 CDT(-0500)] <apetro> with no path to a 3.5 release?
[14:08:16 CDT(-0500)] <apetro> in any case, yes, agree on need to hash out a CAS 3.5 roadmap articulating who's actually going to do what
[14:08:50 CDT(-0500)] <MarvinAddison> Sounds like a plan.
[14:08:54 CDT(-0500)] <MarvinAddison> (thank God)
[14:08:55 CDT(-0500)] <apetro> and then it will be good to think through timeline. I hadn't realized that 3.5 is needed to get to Apache licensing. That's actually giving me significant heartburn. Thanksgiving as a 3.5 release timeline?
[14:09:22 CDT(-0500)] <MarvinAddison> Depending on scope, we could knock it out much sooner I think.
[14:09:29 CDT(-0500)] <MarvinAddison> ever optimist, me
[14:09:33 CDT(-0500)] <apetro> yeah
[14:09:41 CDT(-0500)] <apetro> I have a long history of missing release dates
[14:09:50 CDT(-0500)] <apetro> but yes, it's mostly a bunch of somewhat already existing stuff
[14:10:04 CDT(-0500)] <apetro> so maybe a faster timeline, or maybe keep it scope constrained so it can be a faster timeline.
[14:10:24 CDT(-0500)] <MarvinAddison> Yup.
[14:10:51 CDT(-0500)] <apetro> cool. I'll go look at 3.4.9 so that we can get that release out.
[14:11:04 CDT(-0500)] <MarvinAddison> Same here.
[14:51:05 CDT(-0500)] <apetro> fairwinds, you still here with questions?
[14:53:09 CDT(-0500)] <fairwinds> yup
[14:53:11 CDT(-0500)] <fairwinds> (smile)
[14:53:44 CDT(-0500)] <fairwinds> My first goal is an authentication handler using couchdb's users to authenticate against
[14:54:14 CDT(-0500)] <MarvinAddison> Sounds reasonable.
[14:54:38 CDT(-0500)] <MarvinAddison> Is there a good Java API for CouchDB?
[14:55:14 CDT(-0500)] <fairwinds> it looks like first step is to create module in cas-server.pom xml, then create a custom handler, then add to cas-serer-webapp project
[14:55:31 CDT(-0500)] <fairwinds> yes, there are a few good java clients
[14:55:59 CDT(-0500)] <MarvinAddison> Actually, you should use Maven WAR Overlay.
[14:56:18 CDT(-0500)] <fairwinds> ok, I saw something about that, I will read
[14:56:26 CDT(-0500)] <MarvinAddison> You would go the route you described if you were going to contribute this to CAS core proper.
[14:56:30 CDT(-0500)] <apetro> (I'm distracted on a phone call, but I'll be back in a half hour or so)
[14:56:45 CDT(-0500)] <MarvinAddison> https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
[14:57:16 CDT(-0500)] <MarvinAddison> https://svn.middleware.vt.edu/svn/middleware/cas/cas-server/trunk/ provides a working example of an overlay with custom code that implements CAS API extension points.
[14:57:22 CDT(-0500)] <MarvinAddison> (which is what you intend to do)
[14:57:40 CDT(-0500)] <MarvinAddison> vt-cas-server-ext contains the extensions
[14:57:49 CDT(-0500)] <fairwinds> k, great. next is to understand what handler to inherit from
[14:58:13 CDT(-0500)] <fairwinds> my guess is all I will have to do is override an authenticate method for most part
[14:59:05 CDT(-0500)] <MarvinAddison> AbstractUsernamePasswordAuthenticationHandler is a good one to consider.
[14:59:31 CDT(-0500)] <MarvinAddison> It provides template methods to implement to do the meaningful work, while providing the scaffolding so everything works correctly.
[14:59:51 CDT(-0500)] <fairwinds> couchdb has user and password in _users. Just uses a salt for encrypting passwords
[15:00:35 CDT(-0500)] <fairwinds> k, good. As an alternative to a couchdb java lib, I was looking at groovie rest client and json lib
[15:01:14 CDT(-0500)] <fairwinds> that's groovy actually (smile)
[15:01:29 CDT(-0500)] <fairwinds> I read this today, http://www.ibm.com/developerworks/java/library/j-javadev2-5/
[15:01:31 CDT(-0500)] <MarvinAddison> right, figured
[15:01:59 CDT(-0500)] <MarvinAddison> Looks interesting.
[15:02:09 CDT(-0500)] <MarvinAddison> I'd go with whatever seems most natural to you.
[15:02:15 CDT(-0500)] <fairwinds> leaves it very straight forward since everything in couch is standard json calls
[15:02:32 CDT(-0500)] <fairwinds> http get, put etc
[15:03:02 CDT(-0500)] <fairwinds> it seemed the java couch clients were not so well maintained for some reason
[15:03:10 CDT(-0500)] <MarvinAddison> You might consider just a Java JSON library and do similar.
[15:03:44 CDT(-0500)] <MarvinAddison> And just do the HTTP calls using java.net.URLConnection or something.
[15:04:11 CDT(-0500)] <MarvinAddison> I like to avoid additional dependencies where possible.
[15:04:23 CDT(-0500)] <MarvinAddison> Groovy is a significant dep.
[15:04:26 CDT(-0500)] <fairwinds> k, that sounds good
[15:04:49 CDT(-0500)] <fairwinds> I'd rather few dependencies also
[15:05:12 CDT(-0500)] <fairwinds> I am a bit rough with Java really.
[15:05:34 CDT(-0500)] <fairwinds> I code in other languages but not Java normally
[15:05:45 CDT(-0500)] <fairwinds> but want to get this done
[15:05:55 CDT(-0500)] <fairwinds> so am going for it anyway
[15:06:05 CDT(-0500)] <MarvinAddison> Good for you.
[15:06:43 CDT(-0500)] <fairwinds> do any of you hang out here over the weekend?
[15:07:13 CDT(-0500)] <fairwinds> I will likely have something rough today I would expect later on possibly
[15:07:38 CDT(-0500)] <fairwinds> will likely want someone to talk a look in a paste or something
[15:08:04 CDT(-0500)] <MarvinAddison> I'm very spotty over the weekend.
[15:08:07 CDT(-0500)] <fairwinds> I would expect I should be able to get something going alright
[15:08:28 CDT(-0500)] <fairwinds> sure, np. I will just keep the channel open and look for folks when I am ready
[15:08:56 CDT(-0500)] <MarvinAddison> Sounds good. I'll try to drop by.
[15:09:21 CDT(-0500)] <fairwinds> btw, I was looking at the default auth handler. Where do you put the user passwords to try it in the demo
[15:09:39 CDT(-0500)] <fairwinds> I have the demo configured and running locally on my mac
[15:09:52 CDT(-0500)] <MarvinAddison> Send it an instance of UsernamePasswordCredentials, which has setters for username and password.
[15:10:30 CDT(-0500)] <MarvinAddison> I assumed you meant where in code.
[15:10:55 CDT(-0500)] <fairwinds> yup
[15:12:00 CDT(-0500)] <fairwinds> so there is nothing I need to put in cas-server-webapp?
[15:12:36 CDT(-0500)] <fairwinds> to get a demo working with a couple of user password combinations
[15:13:09 CDT(-0500)] <MarvinAddison> You'll have to provide a custom deployerConfigContext.xml that mentions your custom CouchDB auth handler.
[15:13:40 CDT(-0500)] <MarvinAddison> It's not in cas-server-webapp per se, just overrides the file that's already there.
[15:13:44 CDT(-0500)] <MarvinAddison> That's the nature of an overlay.
[15:13:52 CDT(-0500)] <fairwinds> yes for sure
[15:14:34 CDT(-0500)] <apetro> (back. Looks like this is going in a productive direction. let me know how I can help.)
[15:16:26 CDT(-0500)] <fairwinds> I was looking at authenticating with a couple of name passwords with default authentication handler. Right now, I have demo running but I think the demo does not have any dummy user password combinations but perhaps I am missing something
[15:17:11 CDT(-0500)] <fairwinds> apetro: for sure, I think I am getting good handle on what I will be doing this evening
[15:17:12 CDT(-0500)] <MarvinAddison> The default auth handler succeeds if username==password for any value of username.
[15:17:37 CDT(-0500)] <fairwinds> right: but where are these to be located for the demo
[15:17:50 CDT(-0500)] <fairwinds> I could not seem to find
[15:18:10 CDT(-0500)] <apetro> I don't understand the question?
[15:18:15 CDT(-0500)] <fairwinds> to set a couple of them to verify the default handler does its thing
[15:18:28 CDT(-0500)] <apetro> CAS has no internal store of users
[15:18:43 CDT(-0500)] <apetro> whatever credentials succeed against the configured AuthenticationHandler are okay with cAS
[15:18:50 CDT(-0500)] <MarvinAddison> Any username you choose will get auth'd if you echo the same in the password.
[15:19:05 CDT(-0500)] <fairwinds> ah, k
[15:19:07 CDT(-0500)] <MarvinAddison> apetro is correct – no "default" users
[15:19:18 CDT(-0500)] <apetro> Right. And then once you've succeeded in creating a CouchDb impl, then whichever users you've put in that database will succeed (smile)
[15:20:02 CDT(-0500)] <fairwinds> k, I thought you could use a file as a source of user: passwords for the default handler but maybe it was somethign else I read
[15:20:06 CDT(-0500)] <apetro> Can I ask a stupid question? Does CouchDb speak SQL / have a JDBC driver? Because if it does, you might be able to use an existing AuthenticationHandler implementation for this integration.
[15:20:33 CDT(-0500)] <fairwinds> apetro: no couch is purerly http and REST
[15:20:36 CDT(-0500)] <fairwinds> api
[15:20:40 CDT(-0500)] <apetro> ah. there's a second thing to configure. So CAS ships with a built-in application that uses CAS for user authentication, but then uses something else to enumerate which users are allowed to use it.
[15:20:54 CDT(-0500)] <apetro> the Services Registry
[15:21:07 CDT(-0500)] <apetro> by default you simply enumerate the authorized users in deployerConfigContext.xml
[15:21:25 CDT(-0500)] <apetro> but it's Spring Security, so you can get as complex as you want in how that set of authorized users is implemented.
[15:22:13 CDT(-0500)] <fairwinds> hmm, so is this an alternative to a custom handler
[15:22:15 CDT(-0500)] <apetro> this is also a fine illustrative example of the constrained problem CAS is trying to solve (authentication) and that authorization is left as a responsibility local to the applications relying upon CAS for authentication.
[15:22:26 CDT(-0500)] <apetro> no, not at all
[15:22:32 CDT(-0500)] <fairwinds> oh, sorry
[15:22:34 CDT(-0500)] <apetro> this is two separate things
[15:22:48 CDT(-0500)] <apetro> the AuthenticationHandler is answering the question of how to authenticate users (as in, how to validate usernames and passwords)
[15:23:13 CDT(-0500)] <apetro> the specific-to-the-Services-Registry-application configuration of Spring Security is answering the question of which of those users are allowed to administer CAS through its admin UI
[15:23:17 CDT(-0500)] <fairwinds> right. I have roles in the system once the user is authenticated and authorization is based on roles
[15:23:22 CDT(-0500)] <fairwinds> for the apps
[15:23:25 CDT(-0500)] <apetro> perfect.
[15:24:08 CDT(-0500)] <fairwinds> my concern was primarily authentication since authorization is already being done at app level
[15:25:20 CDT(-0500)] <fairwinds> k, well I think I have enough to get started and writing something. i really appreciate the discussion and help
[15:25:52 CDT(-0500)] <fairwinds> I will be interested in showing what I have done for some feedback later on.
[15:26:05 CDT(-0500)] <fairwinds> can paste my sample code
[15:26:45 CDT(-0500)] <fairwinds> I think i should be good getting somethign working but it might not be pretty on first go
[15:27:11 CDT(-0500)] <MarvinAddison> We'll be happy to review code.
[15:28:47 CDT(-0500)] <fairwinds> super, thanks. I will be trying to get up on a centos server tonight as well. Have my evening planned. too bad it is so hot. Man, no AC and 31C
[15:29:10 CDT(-0500)] <fairwinds> ah well, cooking with CAS
[15:29:13 CDT(-0500)] <fairwinds> (smile)
[15:29:57 CDT(-0500)] <fairwinds> well off to get a bite to eat, talk to you later
[15:30:55 CDT(-0500)] <MarvinAddison> 31C – Guess you're not in US.
[15:31:14 CDT(-0500)] <MarvinAddison> (or you just really love the metric system (wink)
[15:32:05 CDT(-0500)] <MarvinAddison> In any case everyone on the east coast of the US feels your pain.
[20:48:37 CDT(-0500)] <fairwinds> apetro: ping
[20:51:46 CDT(-0500)] <fairwinds> apetro: I am just putting my ovelay together. Have followed instructions at https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
[20:52:08 CDT(-0500)] <apetro> ok
[20:52:31 CDT(-0500)] <fairwinds> so now just looking at how to organize my customizations
[20:52:49 CDT(-0500)] <apetro> cool.
[20:52:51 CDT(-0500)] <fairwinds> I created a folder am-cas-server-ext for them
[20:53:06 CDT(-0500)] <apetro> a single overlay project is a fine way to start
[20:53:25 CDT(-0500)] <apetro> containing all your Java and also all your config mods, CAS skinning, whatever
[20:53:53 CDT(-0500)] <apetro> you could eventually decide to factor out some of the Java as a separate module that builds to a .jar that you can include in your overlay by declaring dependency on it
[20:54:08 CDT(-0500)] <apetro> which steps towards what it would look like if you were to share that extension as something others can adopt
[20:54:30 CDT(-0500)] <apetro> it's not particularly hard, but I'd get it working as just the one overlay to rule them all first
[20:54:40 CDT(-0500)] <fairwinds> ok
[20:55:20 CDT(-0500)] <apetro> saves you having to first learn about Maven versioning and SNAPSHOTs and so forth (smile)
[20:55:43 CDT(-0500)] <fairwinds> right, the structure is the most daunting part (smile)
[20:56:03 CDT(-0500)] <apetro> certainly worth mastering if you're looking for re-use, distribution to others
[20:56:11 CDT(-0500)] <fairwinds> right
[20:56:22 CDT(-0500)] <apetro> but don't let it be a barrier – even an overlay demonstrating your solution will be worthwhile to others to look at if you're going that direction.
[20:57:21 CDT(-0500)] <fairwinds> sure. I will keep trucking. Still hot here. Not cooling off much. AC would be great. It is not normally so hot
[20:58:31 CDT(-0500)] <apetro> I found a power failure here was a blessing in disguise the other day, in that it helped me to discover the significant advantages of working from a cafe with extreme air conditioning.
[20:58:54 CDT(-0500)] <apetro> I'm blessed with AC, but my second floor office still gets hot. Though it's better now that I've swapped out all the incandescent light bulbs.
[20:59:11 CDT(-0500)] <fairwinds> yeah, extreme air would be a beautiful thing
[20:59:38 CDT(-0500)] <fairwinds> yeah I guess bulbs generate some heat
[21:00:08 CDT(-0500)] <fairwinds> where are you located. I am in Nova Scotia Canada
[21:00:33 CDT(-0500)] <apetro> Plymouth, MI
[21:00:44 CDT(-0500)] <apetro> Michigan. United States.
[21:00:52 CDT(-0500)] <fairwinds> about an hour outside Halifax. I really wanted to head to the shore today. Its only 15 minutes away by car
[21:01:10 CDT(-0500)] <fairwinds> ah, I have been through Michigan
[21:02:20 CDT(-0500)] <fairwinds> a good jump in the ocean here will cool you down quick. Almost make you numb its so cold
[21:03:02 CDT(-0500)] <fairwinds> just wish I was closer to the shore to catch the nice cool breeze from the water