| [higgins-dev] Notes for Higgins developers call on Thursday March 6 |
=========
Paula Austel - IBM
* Jeff Broberg CA
* Duane Buss - Novell
* Anthony Bussani - IBM Zurich
* Greg Byrd - NCSU/IBM
* Brian Carrol - Serena
* Tom Doman - Novell
* Andy Hodgkinson - Novell
Valery Kokhan - Parity Ukraine
David Kuehr-Mclaren - IBM
* Mike McIntosh - IBM
Dale Olds - Novell
Uppili Srinivasan - Oracle
* Drummond Reed - Cordance
* Bruce Rich - IBM
* Mary Ruddy - Meristic/SocialPhysics
Markus Sabedello - Parity
* Jim Sermersheim - Novell
* George Stanchev - Serena
* Daniel Sanders
* Paul Trevithick - Parity/SocialPhysics
* Brian Walker - Parity
* Jeesmon Jacob
Carl Binding
Proposed Agenda
Proposed Agenda
===============
1) [Mary, Brian] RSA interop planning
-------------------------------------
- Need separate entry for selector selector functionality
- Need GTK/Cocoa and RCP results to be posted here: [1]
- After all three selectors results are posted, we can collectively
decide which failures to debug in what order.
2) [Mary] Higgins Download Pages
--------------------------------
- Discussion of requirements for (and audiences for)
Higgins downloads pages
3) GTK/Cocoa Selector Builds
----------------------------
- When can start to include builds?
- These builds would be built remotely on Novell's build machines
- Today tire-kickers can't try out the Higgins (vanilla) Linux or OSX
Selectors without first being redirected to the DigitalMe site as
we're currently doing here:
http://wiki.eclipse.org/GTK_and_Cocoa_Selector_Solution
4) RCP Selector Builds
----------------------
- Mike, what tasks remain before we have RCP executables?
- Brian, where did we get up to on feature builds?
- Today tire-kickers can't try out the Higgins RCP Selector
3) [Paul, Jeesmon] Selector Selector
------------------------------------
Proposed next steps:
- Create a new component on the Components page
- Create wiki page for this component and describe latest HSS architecture
- Need to change the FF extension used by GTK/Cocoa to use HSS
instead of directly launching the GTK/Cocoa Selector
- Need to port HSS to OSX (HSS is currently in Java)
- Need to port HSS to Linux (HSS is currently in Java)
5) [Mike] "extensible ISIP-M" i-card format spex
------------------------------------------------
- Status?
6) [Paul] Node -> Entity
------------------------
- Shall we get this refactoring done for 1.0.1?
- Okay with you Jim?
7) [Paul] 1.0.1 Release planning (see [2])
-----------------------------------
- We changed 1.0.1 date to March 28
- Review/discussion
8) [Jim] Procedure for pushing fixes into 1.0 (see [4])
9) [Jim] IdAS data model as nodes (see [3])
10) [Paul] IdAS: Access Control Next Steps
----------------------------------
- Discussion to decide next steps
11) Other topics?
-Paul
[1]
http://osis.idcommons.net/wiki/I3:Cross_Solution_Information_Card_Relying_Pa
rty_x_Identity_Selector_Results
[2]
http://wiki.eclipse.org/Beyond_Higgins_1.0[3]
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg04132.html[4]
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg04098.html
Meeting Notes
===============
1) [Mary, Brian] RSA interop planning
-------------------------------------
- Need separate entry for selector selector functionality
- Need GTK/Cocoa and RCP results to be posted here: [1]
- After all three selectors results are posted, we can collectively
decide which failures to debug in what order.
[Paul] There is no plan at present to test these (GTK/Cocoa and RCP selectors). So we could remove them from the table or fill them in. Why would there be any differences between DigitalME and Higgins. Should be fine. There are time constraints.
[Paul] If we leave it, will duplicate with the Bandit project.
[Andy] Maybe we should combine the columns.
[Paul, Mary] Yes.
{Paul] The intent is to have someone run through this thing. Need to have bugs fixed in both places.
[Andy] Will fill this on.
[Mary] During the OSIS call on Monday, we were requested to have a separate entry for the Selector Selector, as Selector Selector functionality won't be tested as part of Selector testing.
[Multiple disagreements]
[Tony] This is an interop not a function fest.
[Mary] So we won't add the Selector Selector.
2) [Mary] Higgins Download Pages
--------------------------------
- Discussion of requirements for (and audiences for)
Higgins downloads pages
[Mary] The next topic is the Higgins download pages.
[Mary] We need to make it easier to find and access the downloads appropriately. For example, make it easy for an end-user to download a selector, easy to use the instructions or tools that installs it for you. Pointers to a short list of RP parties and card issuers. Audiences include reporters, end-users, developers that are totally new to Higgins, developers who repeatedly consume Higgins, and Higgins developers.
[Mary] We're interested in hearing from people what categories of users and developers we need to support and what particular download features and capabilities they need.
[Jeff] There is great interest on the RP side. I don't need a running relying party. All I want is the token disassembly code. Give directions on certs required, key store. If you have a string representation of a token, it gets validated and returns the claims values. I'm not looking for an auth filter, just the five lines of code need to invoke the (RP) software. (i.e. packaging around the RP code.)
[Andy] I just think about press and analysts. First thing they are doing to want to download a selector. If they come to a downloads page and see 4-5 selectors they won't know what to do. Need to help them decide and walk them through picking one and package it for easy use. We need a guide to Higgins selectors.
[ ?] I strongly second that. We need a guide to selectors: Why is there more than one. We may want the press to try several.
[Drummond] Want to know one other thing. Many don't even understand the information card metaphor. Many press articles are just learning about selectors. Some of this will be short term.
[Paul] The plan is to build a marketing site, so the question is which improvements do we make to the Eclipse site.
[Paul] This is very related to the next two items.
3) GTK/Cocoa Selector Builds
----------------------------
- When can start to include builds?
- These builds would be built remotely on Novell's build machines
- Today tire-kickers can't try out the Higgins (vanilla) Linux or OSX
Selectors without first being redirected to the DigitalMe site as
we're currently doing here:
http://wiki.eclipse.org/GTK_and_Cocoa_Selector_Solution
[Paul] Is this still what you are willing to do?
[Andy] I can do the builds for SUSA and for mac will do a local build on mac in my office.
[Paul] That is great as a stop gap. That will help a lot. And update the wiki pages. The long term need is to have c++ auto builds.
4) RCP Selector Builds
----------------------
- Mike, what tasks remain before we have RCP executables?
- Brian, where did we get up to on feature builds?
- Today tire-kickers can't try out the Higgins RCP Selector
[Paul] Can you talk about where things are?
[Brian] Will be following-up. Expect new capability next week.
[Paul] Even if a feature builds, still need to auto build the executible.
[Mike] I don't know anything about building a single executable that contains that structure.
[Paul] Usually with Eclipse, you just take what you said and zip it up and that is the executable. So all we need to do is that when the features are there.
[Paul] Something an end user can take and download and double click. Good, sounds like we are very close.
4) [Paul, Jeesmon] Selector Selector
------------------------------------
Proposed next steps:
- Create a new component on the Components page
- Create wiki page for this component and describe latest HSS architecture
- Need to change the FF extension used by GTK/Cocoa to use HSS
instead of directly launching the GTK/Cocoa Selector
- Need to port HSS to OSX (HSS is currently in Java)
- Need to port HSS to Linux (HSS is currently in Java)
[Paul] We have It is split into more pieces. There is a very small piece that plugs into FF or IE and the SS exectable. (The HSS is in C++ not java ) When those components are documented and checked in, it would be possible for Higgins as an overall project to check it in. We are working on a next generation AIR selector. We have it so the same Selector Selector can launch any of the selectors.
[Paul] Mike, you are the component owner for the Selector Selector. These are proposed steps. After we check in the code we would retrofit the RCP selector so that they all use the same launch mechanism.
[Mike] Do you have an updated archecture diagram?
[Jeesmon] I already added a table in the component page.
[Paul] When you go to the Higgins Selector Selector page, you do see a generic architecture diagram, not the specific one for a particular platform like windows. Right Jeesmon?
[Jeesmon] Yes.
[Mike] It is unclear from an implementation standpoint some of the interfaces. Are they described?
[Paul] What is status of the API doc.
[Brian] I'm looking into that.
[Jeesmon] In the windows wiki page there is an API documentation link.
[Paul] This is a word document.
[Brian] Yes.
[Paul] There is a lot to talk about here. Mike, we were trying to be helpful to you. We we can look at it and other people can look at it from other platforms. I'm trying to stimulate conversation between Mike and Jeesmon and Jeesmon and Mike.
[Mike] I'm almost always on the IRC channel. It should be easy to find me.
[Brian] From my perspective I would like Mike and Jeesmon to have a conversaton on the phone - Talk though what we have done and get your inputs, and converge on a common design.
[Mike] That is fine. If Jeesmon sent me a meeting invitation for Friday AM or early next week.
[Brian] Early next week would be great.
5) [Mike] "extensible ISIP-M" i-card format spex
------------------------------------------------
- Status?
[Paul] At the F2F, there was some discusion on extending this spec.
[Mike] I'm in the process of getting this updated. Hoping to have an internal version for Friday and a wiki version sometime next week.
[Paul] Great.
6) [Paul] Node -> Entity
------------------------
- Shall we get this refactoring done for 1.0.1?
- Okay with you Jim?
[Paul] The next topic is a perenial favorite. Shall we put this on the 1.0 list? Because Jim and I have a significant amount of work to do to update that code and zillions of wiki pages. So Jim, how do things look?
[Jim ] It took an entire day before. My concern is that it will take longer as node appeared in more places than digital subject. Code using XML parsers use it.
[Daniel] Same as before. There is another factor. This is a change to the API.This is a small percentage change, if you label it a 1.1, this issues is optics to the user.
[Daniel] This is where item 8 becomes important to really understand. That is why you have bug releases on non major version changes. We are treating 1.0.1 as a major change.
[Paul] What we can do is have milestones towards a release. Have 1.0.1 as a milestone towards 1.1.
[Paul] We can have intermediate version.
[Daniel] I'm wondering if we should talk about this after item 8.
[Paul] We need the input.
[Daniel] Compatability issues between releases needs to be well understood and defined. I have people who want bug fixes and don't want to have the API changes. So where do we put bug fixes rather than major changes.
[Jeff] I don't think API changes can go in now.
[Daniel] We have a 1.0. I'm incouraging my people to use it.
[?] How does an end user know it is safe to pull down the latest code?
[?] The version number tells you.
[Paul] Tony you were one of the people who felt optically it wasn't good to increment. To many 1.1 means a new API. 1.1.1 means bug fixes.
[Paul] People use the released version, not a stable build. But then we need to get them bug fixes without change in API.
[Paul] Can't resolve this without the main voice for counter argument.
[Brian] It would be going with the mainstream model..
[Paul] Another way is to not change the name.
[Mike] We decided provisionally. Tony has a point with 1.1 vs 1.0.1. But Daniel also has a point.
[Mike] This discussion is a perfect example of how persons use numbers as a metric on stability. It is a true and honest one.
[Daniel] What if we versioned libraries and the project differently. IdAS might be 1.1, but in 1.0.1. Any project factored because of IdAS woudn't do big increment unless IdAS did.
[Tom] We can pontificate. But as I pointed out in the F2F, what is the Eclipse way? We aren't the only ones dealing with this. What do they do for versioning of jars and perception.
[Paul] I've looked at some other projects. 1.1, 1. 2, 1.3 means 3 API changes. All use the same number, and use 3rd number for versions.
[Paul] The countervailing person is not on the call, so we will carry this forward on the dev-list.
[Jim] There is one other issue I have bug fixes that need to be checked in.
[Paul] You can check fixes into the branch.
[Jim] I will go ahead and check in. So the point is you can check in bug fixes but not API changes to branch.
[Paul] Any objections?
[ok]
[Jim] Before API changes had slowed down. We have more changes now after the release.
[Paul] I think we will be changing an API in some way every few months.
7) [Paul] 1.0.1 Release planning (see [2])
-----------------------------------
- We changed 1.0.1 date to March 28
- Review/discussion
8) [Jim] Procedure for pushing fixes into 1.0 (see [4])
9) [Jim] IdAS data model as nodes (see [3])
[Paul] Do you need anymore input?
[Paul] Brian lets put our heads together.
[Drummond] There are needs related to contextual navigation. So that may be a factor too.
10) [Paul] IdAS: Access Control Next Steps
[Paul] We don't have enough time to do justice to this topic. Haven't digested Tony's email.
[Jim] He needs to know that the Higgins stack isn't the only stack. There will always be an STS. Some people use IdAS in a different way than just to support Higgins tests.
[Jim] I will carveout some time to start proposing an API i.e does user x have permission....
[Paul] Maybe David has a proposal also.
----------------------------------
- Discussion to decide next steps
11) Other topics?
[Paul] We have a requirement to add notification API when we try to build a layer on idas, we need to be notified of changes.
[Jim] We already have that ?? is known in API package.
[Paul] Jim do you want to propose a call? Markus and I are definitely interested.
[Drummond] I want to be on that call.
[Daniel] Is that only if you make the modification?
[Paul] Need to talk about multi-threaded nature..
[Paul] Jim you can coordinate Brian make sure Markus is on the call.
[Paul] Ball is still in my court to propose next call on access control.
[Paul] Urgent item is naming proposal for this week.
-end