[higgins-dev] Notes for Higgins developers call on Thursday, December 4t

["Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx>]

Attendees

 

• Brian Carroll - Serena
• Andy Hodgkinson - Novell
• Drummond Reed - Cordance
• Mary Ruddy - Meristic/SocialPhysics
• Markus Sabedello - Parity
• Jim Sermersheim - Novell
• George Stanchev - Serena
• Paul Trevithick - Parity/SocialPhysics
• Brian Walker - Parity
• Hank Mauldin - Cisco

 

Time: noon EST
Dial-in: 1-866-362-7064 / 892048#

 

Agenda
1. [Brian] 1.1M4 was made available on November 25th

• http://wiki.eclipse.org/Higgins_1.1M4    
• http://wiki.eclipse.org/Higgins_1.1M5 – now working on this milestone
• [Brian] Valerie sent a message last week about the M4 update. M5 is tentatively set for January 9, a little more than 6 weeks.  There is an extra week due to the holidays.  Moved all the unfinished M4 items to M5.  On M5 list, selected some of the higher profile items that are actively being worked on for M5. 

2. [Paul] Java 1.4 vs.. Java 5

• We’ve taken a vote/poll to get a sense of the group.
• Wayne Beaton emailed Mary and I privately and said that he felt that the +1/+2 thing was confusing and recommended that it should have been done as two separate votes. He’s no doubt correct. My apologies for not creating two separate polls
• Jim also said the same thing: he felt there was no way to convey that he preferred +2, but if that fails +1. I think most everyone felt that way
• Results:
• Those for moving everything to Java 5 (+2): Markus, SergeyL, Jeesmon, Daniel, Tom, Paul, Maxim
• Those for allowing selected components to use Java 5 (+1): <same list as above is at least partially implied>
• Those for not allowing any use of Java 5 (-1): Paula, Mike, Greg
• Paul & Mary: We’re leaning towards +1: “allowing selected components to use Java 5” because unlike many other decisions we make, this one may mean that an entire set of developers (e.g. IBM’s developers and potentially others) are disenfranchised. They will find it harder to justify contributing to the project as they believe that it will reduce Higgins 1.1’s adoption due to incompatibility with the installed based of 1.4 compatible JVMs. And as we all know Higgins needs all the volunteers/resources it can get.
• [Paul] I put a lot in the notes for the agenda that you can read. There were some structural flaws with the way I created the vote and I apologize for that. The last paragraph is where Mary and I settled out. If we vote +2 it really makes it difficult for some to put resources into Higgins and that is a very serious down side for us.  On the other hand, there are some components that would really benefit from Java 5.
• [Hank] How will that really work?  Which components would be allowed?  New optional components? 
• [Paul] For new optional ones, that’s easy to do with Java 5. For core items, 1) there is always the option of using Higgins 1.0, which runs on 1.4 or 2) would need to use retrofitting tools or not run it.  I hear what you are saying. Means can’t say that it runs on 1.4 if all of it doesn’t. The other approach is to support both. A component owner could use 1.5, but would still need to support 1.4.
• [Hank] I’m thinking how easy this would be if we allow some to move to 1.5, while others stay on 1.4.  How would they build it?  If only support one version of Java, than the users can’t move forward.  Maybe that is part of IBM’s point, if you only offer one version, of course the customer doesn’t move. I’m not opposed to moving forward, but am concerned about some halfway points that may make it more difficult for customers.  Move forward, or support two if need to.
• [Paul] There might be a distinction between components that run on the server, vs. the client. Might want to be more conservative on the client.
• [Jim] I think the mixed version might work. Keep some core components at 1.4, while allowing some other things to be a 5, but the hard part is we don’t really have a dependency graph. You can’t move the configuration code or IdAS, things that are depended on by other projects. It seems it would necessitate us to move to a make it clearer what the dependency graph is.
• [Hank] Is there enough backward compatibility that anything running in 1.4 would run in 1.5?
• [Jim] That is my understanding. 
• [Hank] Just wanted to make sure.
• [Paul] That’s right.
• {Paul] We need to define more clearly what allowing selected means, and start making core vs. not core clear, and make dependencies clear.  Break the dependence project and break it into individual projects. 
• [Jim] If we do the +1 thing, it does mean that all of the benefits that Markus enumerated, we wouldn’t be able to do any of that in the core modules. Which is probably fine give how much time we see people putting into refactoring. There are some things that would be very nice – like generics so have type safety.
• [Paul] This is also a decision, where we are taking the smallest possible step forward.  We can decide in the future to do something different for 1.5.  This is a tough one and passions run high. We have to feel our way forward.
• [Hank] Maybe an action it should be to test that [backwards compatibility]. 
• [Paul] I think that will effectively happen.

3. [Mary] Website home page progress update.  

• http://www.eclipse.org/higgins/nursery
• Partially complete new home page; still broken links, etc.
• [Mary] We have the new graphics for the new home page based on feedback from the F2F and IIW.
• [Hank] Love them.  Seems great.
• [Paul] Think there is something wrong with images.  I seem them render slowly
• [Paul] From before they were very huge.  Thought they would be scaled down.
• [Mary]  The new images are smaller than the first versions.
• [Paul]- Maybe it is my Internet connection.
• [Drummond] They are slow for me too.
• [Markus] The size is very high resolution.
• [Paul] See, they are still huge.  Need to be resized.
• [Paul] I also think looks great.  Concept is to highlight IdAS and bring it out separately.  We also discussed that door number 1 may not just be i-card selectors.  It may be also include the selector selector.  Or there was some interest at IIW – growing interest - on converging on standard plug-ins.  We need to highlight that also.
• [Mary] The next step is to fix the text and links.
• [Paul]  I also like that there is an overview page.
• [Drummond] Yes.
• [Paul] Any other comments? Jim, do you like it?
  [Jim] Yes.  It’s just that the background is curved on the first picture and not on the new pictures.
• [Mary} I will get that fixed.
• [Paul] I find that the grey text is hard to read.  It needs to be a little darker.
• [Drummond] I agree.
  [Mary] I will fix that.
• [Paul] Great progress.

4. [Brian] STS PPID algorithm update

• SergeyL has completed and tested a patch to org.eclipse.higgins.sts.client
• It is compatible with Microsoft’s CardSpace implementation
• Sergey has requested that Mike review the patch and commit it if he has no objections
• [Brian] Asked for anyone else to take a look at it before committing the patch. If you note on the M5 wiki pages there is also another bug fixed. Will include that when get patched reviewed.  We do need some review.  On our side it tested out ok.  So provide feedback or questions to the dev list.

5. [Paul] Higgins Selector Architecture Harmonization

• We’ve learned a great deal about building selectors by rapidly building 4 different flavors
• We need to converge on a single architecture
• Need to define common component APIs (service descriptions AND component names!)
• Some of us in Parity, Novell, as well as potentially some independent developers and other organizations, are interested in starting work on this.
• We’d start by unifying GTK/Cocoa C++ Selector with the AIR Selector
• http://wiki.eclipse.org/Selector_Architecture_Harmonization
• [Paul] The selectors use a lot of different components. So if we could harmonize the selectors, it would go a long way to harmonizing all of Higgins.
• [Paul] Move towards common components and maybe have multiple implements of each (java, and C++).
• [Paul] As noted, there are many people at Novell and Parity, etc. who are very interested in a converged architecture. Could as a first move make a GTK and AIR version.  If you click on the link, you see the new diagram….
• [Paul]The concept of a package is I think a missing ingredient in our architecture.  A package supports a service, but that package could be implemented by different components. Say a package of selector selector – on Windows it is implemented by one set of components; on a Mac it is implemented by another set of components.  Sometimes one component represents one package. Once I introduced that concept, it made things much clearer. We kind of had this notion, we had bunches of components on the components page.  The selector UI – DigitalMe, and Parity uses AIR, logically it is all selector UI.  There may even be alternative components on a single platform. On Linux for example. You can use this package concept to talk about a Higgins Identity Server. I haven’t gone back and refactored all the wiki pages. In addition to all the issues, we have an architecture that is so complex that it doesn’t fit on one page. With this approach, can have a diagram and then drill down. May have a package within a package.  I dream of a day when we can have a clickable architecture picture and navigate to different implementations on different platforms. We used to have a unified architecture, but as we branched off to quickly implement, we couldn’t do this any more.  I’m feeling pretty good about this approach to managing complexity. Do people have a better word for package?
• [Drummond] I like package. It is a UML word also.
• [Andy] There is a green line from selector client to the identity service. That doesn’t imply does it that the client may have some smarts to talk to a remote STS.  Is that right?
• [Paul] Yes, one of the benefits of this package approach is you can hide a lot of stuff. I you were taking this approach, you would just call the remote STS your self.
• [Hank] Is everything in the blue one package? or is each box one package? I’m working with a media group and think of package as bundled together.
• [Paul] That is not what I meant. A package is bigger than a component. Either multiple components or multiple implementation options.
• [Hank] My only objection is that package is used in other ways in the projects I work on.  I don’t have a better word now. I will think about it.
• [Paul] The architecture is one where there is a fairly smart selector client doing quite a lot on the device. We got encouraged when we hear that someone had got this working on an iPhone.
• [Paul] There is also a missing package. There is also an i-card manager web-app, that should be sitting with a green line down to the identity server also. That is a detail. So Andy, are you otherwise ok with this basic approach?
• [Andy] I think so. We may want to show a line going from the Higgins identity server over to the remote STS.
• [Paul] But the AIR folks want to move more closely to your architecture.
• [Paul] We, [the AIR folks] are looking to use your code.
• [Paul] When I tried to draw the selector client, I found that there is more plugability in the Java client. Your selector client was more purpose built. What I would hope is we could evolve to a fairly modular common architecture, even if in many cases on the client the plug-in point is never used or thin.
• [Paul]At 30K feet this is a common architectural layering.
• [Andy] Ok, I see where you are coming from.

• [Paul] Mary and I were having a conversion with a French Consortium, FC², that is related. They continue to look at Higgins and have some interesting challenges integrating with ID-WSF. When we told them about the new hybrid selector, they said that it lines up with everything we have learned about what one needs to do in a selector.  Orange has been working on this. The idea to link to an image of a card – they independently came up with it. It was good feedback. [That another group independently came up with the same approach.] It may ultimately mean that there is more development work from members of the consortium, if all goes well. 
• [Andy] So they did this independently.
• [Paul] Yes. They may want to collaborate.
• [Paul] Any other topics or comments?  See you next Thursday.
• end 12:44