[higgins-dev] I-Card Registry's use of IdAS

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

I may be alone in thinking this, but why not use IdAS as the I-Card Registry / Abstraction?  This would allow the I-Card Registry to be backed by different card stores, and hopefully (some day soon) we'll already have the registry issues ironed out.

 

Jim

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 2/26/07 9:39 AM >>>

While it is wonderful to have this new energy around these 4 components, we also need to find a way to coordinate the existing _javascript_ & Java efforts by Parity Ukraine on these same 4 components without slowing down either team too much. Some suggestions:

1. Browser Extension: I suspect that HBX could be trivially changed to provide an alternative to the Perpetual Motion plugin (Maxim, please chime in here). Would this be useful?.
2. ISS [Client] UI: I think that the "ISS UI" mentioned in Jim's email is very close to if not the same as the "ISS Client UI" in the Higgins architecture. Is this true? If so, Abhi should take a first cut at documenting the API here. So that the Novell folks can react to it and compare it to what they were thinking.
3. ISS: We should agree and/or discuss whether the API described here by Abhi is the one both teams are using.
4. I-Card Registry: Valery should update this API documentation as soon as possible. The Novell folks should examine this and we should have discussion.
5. At long last it may be worth one of us (any volunteers?) to actually try to use the latest GCJ compiler to prove the proposition that the existing java code for a component, say, ISS, can be compiled to binary and thus perhaps obviating the need for having both Java and C/C++/C# versions.
6. Parity Ukraine (esp. Valery) break its development efforts on the last 3 of these components into finer grained Eclipse Bugzilla items so as to publish to others on the higgins team what we're doing more transparently.

-Paul

---

From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Saturday, February 24, 2007 1:14 AM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] Happenings and ideas around HBX, ISS UI, ISS,and ICard Registry

 

All,

 

In order to achieve some further integration and show some interesting use cases, for the past week or so, we've been prototyping implementations of the modules in the subject line.  For (mainly time-related) reasons , we're having to quicky put these together right now (the implementors barely have time to breathe, let alone time discussing on-list), but we do need to carve out time to get the ideas on-list so we can try to do this in a way that furthers Higgins goals (so I'll try to facilitate that).

 

It's probably best to start by describing the modules, their roles, and how we're trying to build them, and then move the conversation toward how these roles/goals mesh with the existing Higgins architecture, and then map out how to best converge and ensure efforts can be funneled into Higgins.

 

Browser Extension

Being coded with _javascript_, XUL

Consists of a launcher (built with code from Perpetual Motion) 

Roles:

- Browser plugin

- Recognizes CardSpace objects on page

- Launches ISS UI when CardSpace button is pressed

- Configurable to launch different selectors (uses XPCOM to launch)

- Using token returned from selector, posts it back to the RP server.

Interacts with ISS UI (XPCOM)

 

ISS UI

Being coded in C# (because implementor is able to re-use existing code of his -- time-to-delivery is a factor here)

Roles (this is the presentation layer only):

- Presents cards to user

- Allows all cards to be listed

- Presents cards which match selection policy

- allows for cad management (creation, deletion, etc.)

Interacts with ISS (XML-RPC)

 

ISS

Being coded with C++ (seen by the implementor as best choice for deployment as dependencies can be delivered ala RPM thus side-stepping IP issues with dependencies.  Also runs as a daemon, and implementor felt C/C++ was a better fit for this)

Depends on OpenSSL, LibXML2, XMLSec

Roles (Uses ICard Registry to achieve many of these):

- Enumerate all cards (via registry)

- Interact with STS (RST / RSTR)

- Performs selection policy matching

- Performs card management (via registry)

Interacts with ICard Registry

 

ICard Registry

Also being coded in C++ (see above)

Roles:

- Provides an abstraction over numerous card stores

- Allows enumeration of card stores

- Allows enumeration of cards in each store

- Card retrieval / management

- Pluggable architecture for future card stores.

Note that we're thinking about how IdAS could be used as the pluggable metaphor here. 

 

I think a good direction for this discussion to move from here is how these goals compare and contrast with the existing Higgins goals. Note that the Higgins goals (as stated on the component pages) were a primary consideration in designing these.  Then we could start talking about how best to converge efforts.

 

Jim