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.
Being
coded with _javascript_, XUL
- 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)
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):
- Allows all
cards to be listed
- Presents cards
which match selection policy
- allows for cad
management (creation, deletion, etc.)
Interacts with
ISS (XML-RPC)
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
Also being coded
in C++ (see above)
- 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.