| [higgins-dev] Notes from 20070531 Higgins developers call |
|
Attendees
========= Alex Amies - IBM Abhi Schelat - IBM * Andy Hodgkinson - Novell * Brian Carrol - Serena Dale Olds - Novell Daniel Sanders - Novell David Kuehr-Mclaren - IBM * Duane Buss - Novell * George Sanchez - Serena * Greg Byrd - NCSU/IBM * Jeff Broberg CA * Jim Sermersheim - Novell Markus Sabedello Mary Ruddy - Parity/SocialPhysics * Mike McIntosh - IBM * Nataraj Nagaratnam - IBM Paul Trevithick - Parity/SocialPhysics Paula Austel - IBM * Tom Doman - Novell * Tony (The Wolf) Old-McNadalin - IBM Uppili Srinivasan - Oracle * Valery Kokhan - Parity Ukraine -- * Present Agenda ------ * Status of architectural convergence of components implementing HBX through ICard store
** What's the next baby step we can take to move closer to convergence?
Tony: We need better detailed documentation that describe the HBX thru ICard store stacks of components we have today. We have two. What are the roles/responsibilities (now and in the future)? What has each impl done? Are each applicable to each scenario we have? Do we need one for each scenario?
Tony: Will foster a wiki page. Will prod Abhi, Andy for information input. Page will gather the current state and then be used to drive any needed re-architecture, and finally convergence toward that.
* Proposed Configuration Layout for Context Providers
Tom: Not sure we can resolve anything on the call. Still need to read last few messages. Need to re-review XRI stuff.
Mike: What's a context?
Tom: All the contexts we can think of require config
Mike: Imagine a context full of data from differing backing stores
Raj: There's config of a context provider into the framework, then there's config of a specific CP.
Brian: use case: we wanted to set up a CP that is backed by data in two different ldap servers.
Tom: use two contexts
Jim: in the future we could also front them with a joining provider
Mike: a CP is nothing more than a unit of code <group agreement>
<discussion around allowing multiple CP configs for a given CP>
Raj: We need to keep the user experience in mind. Too many config UI panels will be confusing.
Brian: Where does the abstraction happen? What hides the notion of objectclass in an LDAP store?
Jim: IdAS. This happens at the IdAS layer and is (should be) handled in the CP, typically by using rules in the context config.
* IdAS Model: We need to add update ability. Consider using metadata to convey model.
Jim: Will send email on thoughts Hold over action items * Paul: Review component wiki pages and provide feedback * Mary: Put the agreed weekly IRC schedule up on the wiki * All: Review Paul's updated version of Markus' discovery draft and provide comments * Tony: Itemize needed items not covered by the latest OSP * All Component owners: review their components with respect to discovery needs. * Topic for another call, general process for refactoring packages New action items
* Tony: build a wiki and prod owners for info (see "next baby step" above)
* Jim: send thoughts on model as metadata. |