Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Notes from Higgins Developers's Call on August 9th



  Alex Amies - IBM

  Paula Austel - IBM

* Anthony Bussani - IBM

* Jeff Broberg CA

  Andy Hodgkinson - Novell

  Duane Buss - Novell

* Greg Byrd - NCSU/IBM

  Brian Carrol - Serena

  Tom Doman - Novell

  Valery Kokhan - Parity Ukraine

* David Kuehr-Mclaren - IBM

  Mike McIntosh - IBM

  Nataraj Nagaratnam - IBM

  Dale Olds - Novell

  Uppili Srinivasan - Oracle

  Drummond Reed - Cordance

  Bruce Rich - IBM

* Mary Ruddy - Parity/SocialPhysics

* Markus Sabedello - Parity

  Jim Sermersheim - Novell

* George Stanchev - Serena

  Daniel Sanders

  Abhi Schelat - IBM

* Paul Trevithick - Parity/SocialPhysics

  Igor Tsinman - Parity


* Present




Preliminary Agenda




1) Valery's build progress (see [1]). When can other components (e.g. TS)

   adopt the new approach?

2) HBX: HBX/RRPS interface needs to be redesigned to support

   the other credential types defined by CardSpace for authentication

   to an STS (m-card)

3) In progress: integration of new IdAS registry

4) In progress by IBM-Zurich: support for an "embedded I-Card Manager"




5) IPR

*  Status update

*  Packaging discussion for context provider.

*  We will delay 1.0 until have all core Higgins components approved

*  Please review/update all your component pages to make sure the

   third party dependencies are current.




Other agenda suggestions?




1) Valery's build progress

Paul:  Have made progress. Have updated the components wiki to show links where available, and am leaving the column blank where the builds are not yet available.


2) HBX: HBX/RRPS interface needs to be redesigned to support

   the other credential types defined by CardSpace for authentication

Paul: CardSpace has several crediential types. We don't currently support them all. Supporting them all would require re-factoring. Which is an architectural change. Which would mean that it needs to be done by M0.9. So this would delay M0.9. People should let the list know what they think about this tradeoff.

Anthony: We should have a conference call on this.

Paul: Anthony please suggest times when we could have a call.

Anthony: I am on vacation next week. Perhaps the week of the 19th. I will send out an email.


3) In progress: integration of new IdAS registry 

Paul: There has been a lot of traffic on this topic.

Markus: There has  been a lot of feedback. There are no major issues remaining. If no objections, could commit it next week.

Paul: Make sure you give people warning, as it will be a breaking change.

Paul: This is a major part of milestone M0.9


4) In progress by IBM-Zurich: support for an "embedded I-Card Manager"

Paul: There is significant ongoing work in Zurich, When they are further along, Anthony will talk about it. It may involve changes to inter-component interfaces.

Anthony: Have been working on the card manager - issue of same card store, sent an email. Not sure how to manage multiple cards using different card types.

Mary: Some issuers will have multiple card types. This is one of our use cases.

Paul: An i-card provider is an issuer of a particular class of card.   

Anthony: ....

Paul: Today can have simultaneous differing i-card providers. Can different differing i-card providers use a common storage.

Anthony: It should be safe. When request all cards that fulfill the policy, it will go through all your different types of cards if they are stored in the same place.

Anthony: I will send an email to the list with more details.

Paul: To accommodate a new type of card would require making changes to a number of Higgins modules. So it is theoretically possible, but it is radical surgery.


5) IPR

Mary: As of last week we had 21 third party code dependencies that we not yet fully reviewed by Eclipse legal. As of yesterday, we had 18 remaining. While we are doing all we can, at the current rate, we will likely not get all these items reviewed in time for inclusion in the release. The IPR review needs to be complete 1 week before the release review, which must occur at least one week before the release, etc.

Mary: The Jena and JNDI context providers reference a lot of third party code. While many of these packages have already been approved, it is likely that not all of them will be approved for both these CP's in time. So the question is how should we package these items? We can make the Higgins code and the approved dependencies available via Eclipse, and the other not yet approved dependencies available from some other site. We could also, while waiting for the rest of the IPR to be completed, temporarily put a fully packaged version of a CP with all the dependencies on a non-Eclipse site, (Bandit). Let us know what you think would be best.

Mary: There is other third party code that is not yet approved that is used by core Higgins components. We are considering not releasing Higgins 1.0 until these are reviewed so that we can cleanly package our core components. We are monitoring the progress of the IPR reviews and are not yet at the point where we need to make a go-no-go decision on this.

Mary: Since there is a long lead time to approve third party code versions that have not previously been approved by Eclipse, all component owners should review there component dependency pages ASAP to make sure that their component dependency lists are complete, have the correct version numbers and have no obsolete entries.


Wrap up

Paul: We have made a lot of progress with the new build process.

Paul: Greg, would you be a guinea pig to run the automated build on your stuff?

Greg: Sure, will do.


Paul: I will on vacation myself next week, and won't be on the call.


Action Items


Anthony: To send an email with details about simultaneous support for multiple card types.

Mary: Continue to work with Eclipse legal and the committers to proceed with the IPR reviews as quickly as possible. Paul and Greg: Work on having Gregg use/test the new build processes. All Committers: Review your components dependency pages to ensure that they are accurate and complete and don’t contain any obsolete items.





Back to the top