Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Selector Architecture Harmonization"
(→Phase 2) |
(→Synchronizing Card Store (Component Set)) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
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. | 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. | ||
| − | The initial step involves harmonizing the architecture of [[GTK and Cocoa Selector 1.0]] with the architecture of [[Selector 1.1 | + | The initial step involves harmonizing the architecture of [[GTK and Cocoa Selector 1.0]] with the architecture of [[AIR Selector 1.1-Win]] and initially implement this new harmonized architecture in [[GTK Selector 1.1-Win]]. |
| + | |||
| + | === Overview === | ||
| + | |||
| + | Aside from UI differences, the [[GTK Selector 1.1-Win]] performs all processing locally, whereas the [[AIR Selector 1.1-Win]] 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 i-card selector service" (LICS) component that alternative selector UI layers can use. A new [[CardSync API]] would be added to the Higgins server. | ||
==Open Issues== | ==Open Issues== | ||
| Line 31: | Line 35: | ||
[[Image:Lics-v.1.1.123.png]] | [[Image:Lics-v.1.1.123.png]] | ||
| − | ==Synchronizing Card Store | + | ==Synchronizing Card Store == |
Current design: | Current design: | ||
[[Image:Sync-card-store.1.1.120.png]] | [[Image:Sync-card-store.1.1.120.png]] | ||
| − | + | == Server == | |
Implement the new [[CardSync API]] in the [[I-Card Sync Web App]] component. See below: | Implement the new [[CardSync API]] in the [[I-Card Sync Web App]] component. See below: | ||
[[Image:Server-mods-v4.png]] | [[Image:Server-mods-v4.png]] | ||
| − | |||
| − | |||
| − | |||
Latest revision as of 10:20, 6 July 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
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.
The initial step involves harmonizing the architecture of GTK and Cocoa Selector 1.0 with the architecture of AIR Selector 1.1-Win and initially implement this new harmonized architecture in GTK Selector 1.1-Win.
Contents
Overview
Aside from UI differences, the GTK Selector 1.1-Win performs all processing locally, whereas the AIR Selector 1.1-Win 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 i-card selector service" (LICS) component that alternative selector UI layers can use. A new CardSync API would be added to the Higgins server.
Open Issues
This is the place to capture open design issues in this project.
- In the long run if the selector UI runs in a separate process then it needs to authenticate itself to the Local I-Card Service envisioned below. We haven't yet decided how to do this.
- In the long run browser plugins need to authenticate themselves to the Local I-Card Service envisioned below. We don't yet know how to do this.
Top Level Architecture
As you can see we have formalized the separation of presentation from core services:
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.
Local I-Card Service
Overview:
Synchronizing Card Store
Current design:
Server
Implement the new CardSync API in the I-Card Sync Web App component. See below:
