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 "PDS Architecture"

(HBX)
(HBX)
Line 30: Line 30:
 
* .js.pds.connector.common
 
* .js.pds.connector.common
  
Functionality:
+
====Functionality====
 
* When the user's browser lands on a new webpage it:
 
* When the user's browser lands on a new webpage it:
 
** Determines if the user is logged in -- this requires there be a template for the current site (domain) and that it contains an IsLoggedIn script
 
** Determines if the user is logged in -- this requires there be a template for the current site (domain) and that it contains an IsLoggedIn script

Revision as of 16:16, 4 November 2011

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins.funnell.PNG

This document describes the top level Higgins 2.0 PDS components under active development. Here are the bugzilla component names:

  • H2-Client
  • H2-HBX
  • H2-PDS
  • H2-PDS Support
  • H2-ADS
  • H2-Data Model

Front End

There are two front end components: a web client, and a browser extension.

Higgins client 2.0.221C.png

Client

The client is written in HTML and JavaScript and runs in any desktop browser (e.g. IE, FF, Safari, Chrome). In the future we also plan to make it display well on the limited screen size of smartphone mobile browser (e.g. iPhone, Android, etc.).

HBX

The Higgins browser extension makes possible functionality like browser-side integration with other web APIs and sites, scraping and form filling.

  • .bx.abx-chrome
  • .bx.abx-common
  • .js.pds.cde - Connection Data Engine. Loads CDE-compatible JSON Scripts (See App-data vocabulary) from templates and uses them to implement auto-login, auto-registration, form filling, etc.
  • .js.pds.connector.common

Functionality

  • When the user's browser lands on a new webpage it:
    • Determines if the user is logged in -- this requires there be a template for the current site (domain) and that it contains an IsLoggedIn script
    • If the user is not logged in then
      • It automatically logs the user in (or should it just auto-fill in the userid/password and wait for the user to click?)
    • Looks for every form on the page
      • Automatically fills in each form as best it can -- this requires there be a template for the current site (domain) and that it contains a Fill script for this form (is there one fill script container with lots of per-form-submit-URL scripts? Or are there lots of Fill scripts each with an for-this-form-submit-URL attribute?
    • Waits for the user to submit a form (including a login form)
      • Scrapes the form submit data and writes it into the PDS. If it is a login form then it writes into the proxy object, else the corresponding context
  • When the user opens a connection details page in the portal
    • It tries to login and scrape the latest data values from the site? Or will this take too long and thus be too annoying?
    • If the user edits an attribute it writes the updated attribute value to the site

Back End Components

There are three back end components mostly written in Java and running in the cloud (e.g. Amazon AWS):

  • PDS
  • PDS Support
  • ADS
Higgins server 2.0.230.png

PDS

PDS Subcomponents:

  • .pds.usermanager.ws - simple web service to manage user accounts, change password, etc.

PDS Support

PDS Support Subcomponents:

  • .pds.client - wrapper around Open Anzo java client

Attribute Data Storage

ADS Subcomponents:

  • PLANNED: .ads.ld - Linked Data endpoint

Data Model

Data attributes whether created by the user or imported from an external service are stored in a common data model. This allows them to be consistently displayed to, and in some cases edited by, the user irrespective of its original source. We call this the Persona Data Model 2.0.

Back to the top