Difference between revisions of "Selector Architecture Harmonization"

Revision as of 11:56, 17 December 2008

Since Selectors use most of the Higgins Components, work on harmonizing the Higgins selectors into a single architecture would be a huge step towards overall Higgins architecture harmonization/convergence.

A good first step in converging the selectors is start by harmonizing the GTK and Cocoa Selector and the Adobe AIR Selector.

Top Level Diagram

Notes:

• Introduce the notion of a "Component Set" -- a set of components
• This architecture would run on Windows, Mac OSX, Linux and (with further work) potentially smart phones
• The "Selector UI" component would be either GTK, Cocoa or AIR-based, but the underlying "Selector Client" would be common.

Phase 1

Phased approach to implementation.

First Steps

The first objective is to perfectly align the existing Components with the above diagram.

1. Jeesmon: Split the shared tcpserver project into multiple projects to align with above. Suggestions for new names:
   • org.eclipse.higgins.hss for http://wiki.eclipse.org/Components#Higgins_Selector_Selector_.28HSS.29
   • org.eclipse.higgins.hss.manager for http://wiki.eclipse.org/Components#HSS_Manager
   • org.eclipse.higgins.hss.launcher for http://wiki.eclipse.org/Components#Higgins_Launcher
   • org.eclipse.higgins.hbx.ie (NOT hbxie! (taken)) for http://wiki.eclipse.org/Components#Higgins_Browser_Extension_.28HBX.29
2. Jeesmon: Merge the currently separate HSS connectors into .higgins.hss per the following ticket 258504
3. Jeesmon: Split the AIR Selector code (org.eclipse.higgins.air ) into two project files
   • org.eclipse.higgins.selector.ui.air - selector UI in AIR/Flex
   • org.eclipse.higgins.selector.client.air (will eventually be replaced with a common .higgins.selector.client in C++) - selector services in AIR/Flex
4. Split GTK/Cocoa Selector component into smaller pieces. Here's the first split:
   • Leave "org.eclipse.higgins.cbselector" project as-is (for Higgins 1.0 use)
   • Split out just the GTK-based user interface portion of .cbselector (shown in a box here) into its own project (e.g. .higgins.selector.ui.gtk) as the first alternative implmentation project within the new Selector UI component shown above.
5. Change GTK-based Selector to use standard Higgins HBX

Phase 2

Client Side

The client side of phase 2 involves replacing the current i-card store in .cbselector with an i-card cache

Overview:

I-Card Cache (Component Set)

One possible way to implement the I-Card Cache:

Implementation Notes:

• As shown above, one way to proceed would be to create (possibly by cross compiling the java code to native code) a local I-Card Registry and local I-Card Providers. We'd need to explore the feasibility of doing this. Note: the IdAS Client and XDI CP (both shown above) have been cross compiled using GCJ by Markus successfully.
• Valery should run a test to work with Markus as needed to cross compile the java code to native code a local I-Card Registry and local I-Card Providers.
• Do we need XDI CP/Idas Client vs. RPPS/SOAP interface?
• Where is the actual cache component?

Server Side

We support the client via the XDI Engine. See below:

Tasks:

• Need to make sure that the personal and managed cards are stored in IdAS rather than locally in the i-card providers. This is done by using the right plugins, (e.g. icard.provider.managed and not icard.provider.managed)
• Need to design how the XDI Engine authenticates to IdAS (does it need to interface with the User Profile Component?)
• Need to change the CPs that store cards to update timestamp metadata on attributes