Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Selector Architecture Harmonization"

(Should we use Google protocol buffers in Card Sync Protocol?)
(Synchronizing Card Store (Component Set))
 
(43 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
[[Image:Higgins_logo_76Wx100H.jpg|right]]  
 
[[Image:Higgins_logo_76Wx100H.jpg|right]]  
  
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.
+
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.  
  
This wiki page is being used to coordinate this project to harmonize the architectures of the [[GTK/Cocoa Selector]] and the architecture of the [[AIR Selector]].
+
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==
 
This is the place to capture open design issues in this project.
 
This is the place to capture open design issues in this project.
  
=== Should we use WebDAV in [[CardSync Protocol]]? ===
+
# 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.
Reasons For:
+
# 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.
* reduces our development effort as this protocol is designed for resource synchronization. And that's what we're doing
+
* mature, widely supported. Being used in new projects such as Mozilla Weave.
+
 
+
Reasons Against:
+
* Not RESTful. WebDAV extends the HTTP verb set. As such is deprecated by the W3C.
+
* Can interfere with web cache architectures
+
 
+
=== Should we use Google protocol buffers? ===
+
Reasons For:
+
* Mature
+
* High performance
+
* Good libraries in both C++ and Java
+
Reasons Against:
+
* Question: Might using protobuf reduce the likelyhood of the CardSpace team collaborating with us and potentially adopting the [[CardSync Protocol]]? <-- an outcome that would increase interoperability in the industry
+
  
 
== Top Level Architecture==
 
== Top Level Architecture==
Line 37: Line 27:
 
* The "Selector UI" component would be either GTK, Cocoa or AIR-based, but the underlying [[Local I-Card Service]] would be common.
 
* The "Selector UI" component would be either GTK, Cocoa or AIR-based, but the underlying [[Local I-Card Service]] would be common.
  
==Phase 1==
 
  
The first objective is to perfectly align the existing [[Components]] with the above diagram.
 
# 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
 
# Jeesmon: Merge the currently separate HSS connectors into .higgins.hss per the following ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=258504 258504]
 
# 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
 
# Andy: 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 [http://wiki.eclipse.org/GTK_and_Cocoa_Selector#Architecture here]) into a new project .higgins.selector.ui.gtk as the first alternative implementation project within the new [http://wiki.eclipse.org/Components#Selector_UI Selector UI] component shown above.
 
#* Copy the rest of the .cbselector project into a new .higgins.lics ([[Local I-Card Service]]) component
 
# Change GTK-based Selector to use standard Higgins [http://wiki.eclipse.org/Components#Higgins_Browser_Extension_.28HBX.29 HBX]
 
  
== Phase 2 ==
+
==Local I-Card Service ==
 
+
===Local I-Card Service ===
+
The client side of phase 2 involves creating the .higgins.lics project by copying the "Identity Selector Service" from the .cbselector and replacing the its i-card store with an i-card cache
+
  
 
Overview:
 
Overview:
  
[[Image:Lics-1.1.121.png]]
+
[[Image:Lics-v.1.1.123.png]]
  
===I-Card Cache (Component Set)===
+
==Synchronizing Card Store ==
One possible way to implement the I-Card Cache:
+
Current design:
  
[[Image:Card-cache-1.1.117.png]]
+
[[Image:Sync-card-store.1.1.120.png]]
  
===Server Modifications===
+
== Server ==
  
A new, RESTful binding [[I-Card Sync Web App]] component would be layered over an enhanced [[I-Card Service]].
+
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]]
 
=== Card Sync Protocol ===
 
 
* [[CardSync Protocol]] - a new RESTful wire protocol used between the new [[Card Sync Web App]] and the new [[Synchronizing Card Store]]
 
 
== Phase 3 ==
 
This phase is about adapting the [[AIR Selector]] to the new architecture.
 

Latest revision as of 10:20, 6 July 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

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.

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

This is the place to capture open design issues in this project.

  1. 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.
  2. 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:

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.


Local I-Card Service

Overview:

Lics-v.1.1.123.png

Synchronizing Card Store

Current design:

Sync-card-store.1.1.120.png

Server

Implement the new CardSync API in the I-Card Sync Web App component. See below:

Server-mods-v4.png

Back to the top