Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Selector Architecture Harmonization"

(Local I-Card Service)
(Local I-Card Service)
Line 45: Line 45:
 
Overview:
 
Overview:
  
[[Image:Lics-1.1.120.png]]
+
[[Image:Lics-1.1.121.png]]
  
 
===I-Card Cache (Component Set)===
 
===I-Card Cache (Component Set)===

Revision as of 14:44, 2 January 2009

{{#eclipseproject:technology.higgins}}
Higgins logo 76Wx100H.jpg

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 AIR Client and Server. Aside from UI differences, the former performs all processing locally, whereas the latter presents a local UI but relies on a hosted server. The latter has the advantage of supporting roaming of cards as well as multiple simultaneous clients. The former has performance advantages. We'd like to get the best of both worlds by having a converged architecture which synchronizes cards between the client and the server. The common code would be in a local "selector service" component that alternative UI layers can use.

Top Level Diagram

As you can see we formalize the separation of presentation from core services:

Unified-selector-1.1.116.png

Notes:

  • We 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 Local I-Card Service 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:
  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.lics Local I-Card Service 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)
    • Copy just the GTK-based user interface portion of .cbselector (shown in a box here) into a new project .higgins.selector.ui.gtk as the first alternative implementation project within the new Selector UI component shown above.
    • Copy the rest of the .cbselector project into a new .higgins.lics (Local I-Card Service) component
  5. Change GTK-based Selector to use standard Higgins HBX

Phase 2

Local I-Card Service

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

Overview:

Lics-1.1.121.png

I-Card Cache (Component Set)

One possible way to implement the I-Card Cache:

I-card-cache-1.1.116.png

Server Modifications

The I-Card Service Web App and I-Card Service would be extended to support the enhancements to the existing client/server protocol.

Server-mods-v2.png

Client/Server Protocol Extension

This section should describe new and/or modified SOAP messages necessary to support the I-Card Cache (client).

<to be written>

Phase 3

This phase is about either adapting the AIR Selector to the new architecture, or dropping support for AIR-based Selector UI component all together.

Back to the top