| [higgins-dev] Notes for Higgins developers call on September 16 |
|
Notes
for Higgins dev call – Sep 16, 2010 Attendees
Logistics ·
Time:
Thursday noon Eastern (16:00 UTC) U.S. ·
Skype:
+9900827047990866 ·
Dial-in:
1-201-793-9022 passcode 7990866# Agenda
·
Mary:
We are getting requests to change the time (some earlier and some later). ·
Paul:
Maybe we could alternate. ·
Valery:
I want it earlier. ·
Mike:
First topic on the agenda. Paul suggested we alternate between earlier
and later and try to divide the topics on each alternating call between the
expected audiences. Maybe every other week we can put on topics best
addressed by Europe, and every other week topics of interest to
California. I think it is worth a try. ·
Paul:
The reason I suggested 10:30 is to try to accommodate a little of the West
coast. But if we alternate we could go for 10:00 and 12:00 ET. ·
Mike:
It is important to get as many of the euro developers as possible to participate
on the calls. ·
Paul:
Do you have a specific proposal that would be easy to remember? ·
Mike:
The proposal is next week’s call is at 10:00 and the week after at 12:00
and alternate very week forward. ·
Valery:
That may work. Let’s try to do it. ·
Mike:
Concerning 1.1M8, there is one item that shows up. It just needs to be
closed. ·
Mary:
Are we done? ·
Mike:
Yes. 1.1M8 is done. ·
Mary:
Do you think 1.1M9 is still late October? ·
Mike:
I do. We have some internal resource allocation issues. Alex is in
the depths of some other more general design questions and the Higgins branded
iPhone selector. One challenge we have right now is at what point can he
take time to get the iPhone selector cleaned-up and resubmitted to Apple.
And whenever we do that, he is unavailable for other work. Late October
is still our target. Maybe Alex can tell us where he is right now. ·
Alex:
I need a couple days to finish the iPhone app. ·
Mike:
So theoretically we can resubmit this to Apple for approval. So by the
end of next week we will resubmit this to Apple. It usually takes 3 weeks
to hear from them. If there is no issue we can meet the mid to late
October date. ·
John:
The last iPhone app I updated, they turned it around in 24 hours. That
was in the last week. I wouldn’t count on it. But there are
miracles. ·
Mary:
So leave it at 22nd. We understand there is a known risk with
the iPhone. ·
Mike:
There is the issue to find the time to make the change, and approval and number
of iterations needed [to get approval]. ·
Mary:
OK. Leave it as is. ·
Mike:
Yes. We will know more in a few weeks when we hear back from Apple. ·
Paul:
When I look at the URL the dates are not updated ·
Mary:
There was an issue about exactly when 1.1.M8 was done. ·
Paul:
I changed it from 7/11 to Sep 3. ·
Mike:
Sep 3 is correct. ·
Mary:
The 22nd of October has known risks. What about RC1? ·
Mike:
RC1 is the same as M9. ·
Paul:
I will move both to 10/22. ·
Mary:
The next item is OpenID for java. ·
John:
There is one guy who is still outstanding. His contribution was just a
bug fix. ·
Mary:
So is the solution to back it out? ·
John:
Johnny doesn’t consider it significant. Everyone else has signed. ·
Mike:
So would Eclipse, from a process point of view let us do that? ·
Mike:
I could redo the bug fix. ·
Mary:
This is the gating item. ·
John:
I have some time this afternoon. ·
Mary:
John, can we get Johnny to remake the change? ·
Paul:
Do we even use this? Or could we just move it into a nursery area? ·
Mike:
We need to check what links to it and see if we can isolate it. I think
it was Markus who used it. ·
John:
It was used in Markus’ cloud selector. ·
Paul:
That is right. ·
Paul:
If we take the bug fix out, then someone else can remake it? ·
Mike:
Do we have the ability to do that? ·
John:
I have a list of revisions. I will send Mike what I have. ·
Mary:
The next item is Tom. ·
Tom:
At one point we had talked about a fairly wide press release. One of the
participants is taking longer. Mydex needs to get this out before early
October. They want to go ahead even it if is smaller scope. ·
Mary:
I’m ok with that. ·
Mary:
The OK from Eclipse was broader. We can’t assume that they
would be interested. ·
Tom:
OK ·
Mary:
What would the narrower release include? ·
Tom:
Could still include Google, if we want to. I just don’t think the
Cambridge crew is going to be ready. ·
Mary:
So could you draft it and we can run it by Eclipse? ·
Tom:
OK. ·
Mary:
Next topic. ·
Paul:
I’m really excited about the picture it is simpler. Let go into
that paragraph here. [Paul read from the link] A persona is a group of
attributes…. Has the latest on what is a card, and what is a
persona. A card can be part of multiple personas… ·
Mike:
I think we will get into more feedback in the next agenda item. ·
Mike:
The next agenda item is the app card design review. There is an app card
wiki page and app data howl. ·
Paul:
If you look at the first link and scroll-up there is an UML overview. An
app card is a special kind of R- card, which is a special type of card.
An app card has a pointer. The value of the claim is a UDI pointer to a
personal object in a data store….. Has a resource UDR claim. The
innovation we added is a template to the app card. There are two kinds of
app cards. 1) Something that someone mints about you - your AAA card. But
Tom has pointed out many times a company wants to mint a card that is a
template and have the active client dynamically make the app data context that
binds the data to the card. ·
Mike:
When we create the app card specific data. Some apps work on one RP. Some
on multiple RP’s ·
Paul:
… ·
Mike:
So there is a card context that points to an app data context. Then if we
go to different RP’s … ·
Paul:
There is a hyperlink that brings you to a wiki page with a concrete
example. It shows an actual card…..if you scroll down the example
app card and data, you can see those are two different contexts. ·
Mike:
Are we ready to move to the next link? ·
Paul:
Yes. ·
Mike:
Alex do you want to walk us through understanding app cards document? I
turned it to a pdf and put a link here. There are a few places where the
word Azigo needs to be replaced with Higgins. ·
Mike:
Need to make sure the app data is refreshed on the user’s machine. ·
Paul:
The root… ·
Mike:
We will go through Alex’s document. ·
Alex:
…. ·
Mike:
The question is how complicated would it be to implement something that has
these dependencies. It seems very difficult to think ahead of time of all
the possibilities and to process that kind of file in a generic way. It
is almost that the app card itself is the only thing to say what its
environment is. It seems very difficult to have the framework solve this
generically. ·
Paul:
I agree. ·
Mike:
The easy way to that is …. ·
Paul:
CardSpace has no way to inspect the contents of the card itself. We are
trying to stay as close to that as possible. So I keep pushing on loose
dynamic bindings. You list the attribute and can list the issuer on an
attribute by attribute basis, indicating who you trust. ·
Alex:
… ·
Paul:
When a selector pops-up you ask the user to disambiguate, or… ·
Alex:
… ·
Paul:
I’m hoping that the xxx method can do all of these. ·
Mike:
The challenge is that we don’t yet have too many examples of apps that need
each other around. The example is a gov card that needs access to
verified address info from another card. I guess in the context of that
conversation we need to figure out how the gov card figures out that the
address has been verified. It is also possible that potentially the gov
card may need things from multiple places. We need to work though this
more to figure out the right solution. I’m working on a flow chart
on how exactly attributes work. I’m uncovering lots of detail that
I need to figure out what to do. It needs to be an iterative
process. Hopefully we will have something to discuss in two weeks.
Need to figure out how we know we have not just the right card, but the right
version of that card. ·
Paul:
There are two data models, the underlying vocabulary and the specific set of
approved attributes. They could both change. ·
Mike:
We need to know about both of them. ·
Alex:
… ·
Mike:
If installing an app card, if it is going to read attributes... I will spend
some time looking into this. ·
Paul:
Next week, the call is at 10:00AM. |