Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] DRAFT 2: Agenda for December 4th Higgins Developer Call

Title: DRAFT 2: Agenda for December 4th Higgins Developer Call
Time: noon EST
Dial-in: 1-866-362-7064 / 892048#

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

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.

3. [Mary] Website home page progress update.  

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

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

Attachment: ATT00001.c
Description: Binary data


Back to the top