PDS Use Cases

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

Create a connection to a site from a card in gallery

Cards represent a relationship between the user and an external site or business. The relationship includes a bi-directional data connection that shares and synchronizes a set of attributes between the site and the user's PDS. This set is a site-specific subset of the user's attributes.

The card gallery contains a set of pre-defined card templates (all of class ConnectorTemplate, and all of whose Definer Connector are of class WebsiteFacade). When the user clicks on one of these templates, it creates a pair of connection contexts as described here (). The WebsiteFacade>Definer>ContextPrototype instance has an an associated app-data:JavaScript entity that contains a JavaScript that, when loaded into the HBX runtime environment, acts as a facade over a plain-old website. The facade uses HTML scraping to pull attributes from the site, and uses form filling to push attributes to the site, thereby synchronizing the contents of the WebsiteFacade>Definer>ContextPrototype with the site.

The JavaScript runs quietly in the background and doesn't interact with the user at all.

Story

1. She navigates in web client to a place where a gallery of available templates is displayed
2. She clicks on the "Google Ads" card-shaped template
3. She sees a new Google Ads card in her list of cards

Assumptions

1. Alice is already logged in to her PDS web client
2. The PDS includes a card gallery
3. PDS gallery is pre-configured with a set of template contexts and one of these is the Google Ads template.

Design

Data model:

• Template vocabulary shows an example template--this example is the Google Ads template

Issues:

• Q: How does the PDS code know by inspection of the card gallery whether the PDS user is the definer/creator of the template? In other words how does it know which role (definer vs. participant) it should play?
  • A: If the card is in the gallery at all, we will assume it was defined by an external (non-user) definer. We'll put user-defined templates somewhere else.
• Q: how is the connectionType for the Proxy determined from the template?
  • A: See Template vocabulary#UML_Overview--the tempalte has a proxy:connectiontype attribute whose value should be copied to the Proxy.
• Q: A crude and simple design would be do introduce a dirty bit notion to contexts. Whenever the user (either directly, or as a side effect of attribute change propagation) modifies a context, its "modified" timestamp is updated. The JavaScript (whether signaled directly or via polling) can compare this timestamp with a stored value. If it is more recent then it attempts to re-sync all attributes.

Logic:

1. Flow stars in portal. User opens the card gallery. User selects card to add. For consistency we very roughly follow the context building flow here Person-site Relationship Management.
2. Client instantiates the participant context based on the Participant prototype in the template
3. Client instantiates the definer context based on the Definer prototype in the template. It also adds an h:correlation link from the newly minted p:Person in the Definer context to the p:Person in the Participant context
4. Client adds the reciprocal h:correlation link

Create a connection with a site that natively supports (some) connection protocol

Story

User goes to a site that allows a PDS-to-site connection. (We're being vague here about the protocol because we assume it can entirely be done using the hot-off-the-presses OpenID Connect protocol, but we're not yet sure).

Design

• See Person-Site Relationship Management

Edit simple or complex attribute of a card

Story

1. She navigates to a place that shows her list of cards
2. She clicks on a card (e.g. Google Ads") to select it
3. The card displays a set of attributes
4. Alice edits the value of some attribute

Assumptions

1. Alice logs into web client

Design

• Context Editor Design Notes