Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Shibboleth Developer's Meeting, August 9, 2013

Attendees: 

Call Administrivia

Dial-in attendee identification.

Next call is next Friday. Any reason not to meet ?

60 to 90 minute call window.

 

Brent

Have started working on refactoring of metadata support to MetadataResolver API.  Will likely have a couple of questions/issues to discuss on the list.


Daniel

 

Ian

Nothing to report.

Marvin

Nothing to report.

Rod

  • Did the schema validation thing.
  • Did the spring bean config for  the attribute mapper
  • Rest of the week spent in a cleanup pass over attibute-filter for Tom.
  • Next up:
    • Cleanup pass on Attribute Resolver
    • Auto generate Attribute mapper config
    • Topical bug fixing
    • TOU/Attribute release.
    • More attribute filter documentation?
    • ????

Scott

 

Tom

The primary task on my mind is performance testing. I currently do not have any sort of harness set up to examine Web Flow, and I think I should. An example would be to try and measure if there is a discernible impact on performance or cpu for stateless vs stateful action beans. My hypothesis is that I will not be able to discern much difference, but the test harness itself would be worthwhile, to me.

Before performance testing, I wanted to get Velocity figured out, and although there are issues to resolve, I think we'll be okay. As a recap, on the last call and on the dev list it became clear to me that Velocity will not replace our ResourceFilter, but rather we would provide a VelocityResourceFilter. One issue I can think of is bootstrapping Velocity to parse our configuration files via the ResourceFilter API, I imagine that instance of Velocity will be spun up and spun down just for that purpose. Consequently, I assume that we will probably want to externalize the Velocity configuration.

Another comment about Resources is that I would like to understand why the HttpResource should be replaced. If someone else gets to it, please summarize for me, that would be nice.

I think I should create the idp-attribute-mapper-api|impl modules and move over Rod's work there, I think we have agreement on that.

I should create a JIRA issue for the default permit any <AttributeRule /> "feature", see if there is any traction, but slate for 3.x, meaning it does not have to be done for 3.0 if we do it at all.

Git. I think it would be good to have a summary, perhaps on the wiki, of our current stance.

Bikeshedding. Disclaimer : I actually have a bike shed and it needs to be painted, white vs barn-red, not sure. I purposefully bikeshed-ed regarding getLdapUrl vs getLDAPURL, because it was interesting, but I do want to spend our time wisely.

These calls. I have tried to minimize my "lead"ness on these calls because I actually feel like I do a pretty horrible job of it, so constructive feedback is appreciated, and I am totally open to changing things.

Other

 

 


  • No labels