Page Comparison

...

1. VIEWER - The entity for which gadget is currently being rendered.
2. SUBJECT - The data that is currently being handled by the gadget
3. SUBJECT OWNER - The entity that owns the SUBJECT dataAPP OWNER - The entity responsible for the gadget instance
4. CONTEXT - The context into which the gadget instance is included (e.g. the page it is installed on)CONTEXT OWNER - The entity responsible for the context into which the gadget instance is included
5. SOURCE - The source of the gadget specification (identifies the entity that created the gadget)

...

• VIEWER is the user viewing the profile data
• SUBJECT is the profile data being displayed.SUBJECT OWNER is the entity that owns that data, be it a person or an organization, etc
• APP OWNER is the entity responsible for adding the profile gadget instance to the page
• CONTEXT is the page onto which the gadget is displayed
• CONTEXT OWNER is the entity responsible for the page on which the profile gadget instance is displayed
• SOURCE is the entity that provided the profile gadget code

...

• VIEWER is the user viewing the profile data
• SUBJECT is either the file or the folder being displayed.SUBJECT
• OWNER is the entity that owns the file or the folder, be it a person or an organization or a "space", etcAPP OWNER is the entity responsible for the files gadget instance itself
• CONTEXT is the page onto which the gadget is displayed
• CONTEXT OWNER is the entity responsible for the page on which the profile gadget instance is displayed
• SOURCE is the entity that provided the profile gadget code

Currently, the single, poorly defined OWNER role is used ambiguously by containers to represent SUBJECT, SUBJECT OWNER, APP OWNER, CONTEXT , CONTEXT OWNER and SOURCE... which isn't adequate for a variety of reasons.

SUBJECT is the most difficult to define of the roles since it may not necessarily represent a single data object, but a composite of information from multiple sources and multiple owners compiled dynamically by the gadget itself. For instance, a gadget may display data from a profile, a list of files, and an activity stream. In such cases, the SUBJECT would be considered to be "composite" and the container will be likely be unable to reliably determine a single SUBJECT OWNER.

...

The specific extent of this change would need to be determined. However, the following changes would be apparent:

• For signed fetch, oauth and oauth2... right now, we say that the identity of the "viewer" and "owner" can be included in the request, but there's no clear definition of what the "owner" signifies in this case. With this change, these would be modified to allow the identity of the VIEWER, APP OWNER and CONTEXT OWNER. The identity of the SOURCE could be included but would be entirely optional and likely not very useful. The identity of the SUBJECT and SUBJECT OWNER typically should not be important to a remote resource and would generally be very difficult or impossible for the container to reliably determine. The parameters would be:
  • opensocial_viewer_id (specifies who the remote content is being requested for)
  • opensocial_gadget_owner_id (specifies the container's notion of who owns the instance of the gadget that is requesting the data... might be the same as viewer_id but might not)
  • opensocial_gadgetapp_id (specifies the container's unique identity for the gadget application instance that is requesting the data.. this would be optional... a remote service might provision access to content to individual instances for billing or other administrative purposes, etc)opensocial_context_owner_id (specifies the container's notion of who owns the context in which the gadget instance is installed)
  • opensocial_context_id (specifies the container's unique identity for the context into which the gadget instance is deployed.. this would be optional.. a remote service might provision access to content based on the context to which a gadget is deployed for billing or other administrative purposes... for instance, a profile gadget might only be permitted to access remote student information if it's deployed on a context related to a particular course)
  • opensocial_gadget_source_id (specifies the container's notion of who provided the gadget specification)
  The following Reserved Variable Keys would be accessible for variable substitution. Note the SUBJECT and SUBJECT OWNER are not covered by the Reserved Variable Keys. These are going to be different for each gadget and it may be impossible for the container to reliably determine any useful information about the subject and it's owner, making it the gadgets responsibility to provide those details.
  • ${VIEWER.*} (VIEWER)
    • ${VIEWER.id}
    • ${VIEWER.type} (OpenSocial Data Type)
    • ${VIEWER.*}
      • e.g. ${VIEWER.displayName}, ${VIEWER.name.givenName}, etc
  • ${GADGET.*}
    • ${Gadget.id} (container assigned gadget instance unique identifier)
    • ${Gadget.title} (ModulePrefs/@title)
    • ${Gadget.title_url} (ModulePrefs/@title_url)
    • ${Gadget.description} (ModulePrefs/@description)
    • ${Gadget.author} (ModulePrefs/@author)
    • ${Gadget.author_email} (ModulePrefs/@author_email)
    • ${Gadget.screenshot} (ModulePrefs/@screenshot)
    • ${Gadget.thumbnail} (ModulePrefs/@thumbnail)
    • ${Gadget.height} (ModulePrefs/@height)
    • ${Gadget.width} (ModulePrefs/@width)
    • ${Gadget.doctype} (ModulePrefs/@doctype)
    • ${Gadget.*}
  • ${GADGET.Owner.*} (APP OWNER)
  • ${GADGET.Owner.id}
  ${GADGET.Owner.type} (OpenSocial Data Type)
  • ${GADGET.Owner.*} e.g. ${GADGET.Owner.displayName}, ${GADGET.Owner.name.givenName}
  • ${GADGET.Source.*} (SOURCE)
    • ${GADGET.Source.id}
    • ${GADGET.Source.type} (OpenSocial Data Type)
    • ${GADGET.Source.*} e.g. ${GADGET.Source.displayName}, etc
  • ${CONTEXT.*} (CONTEXT)
    • ${CONTEXT.id}
    • ${CONTEXT.type}
  • ${CONTEXT.Owner.*} (CONTEXT OWNER)
    • ${CONTEXT.Owner.id}
    • ${CONTEXT.Owner.type}
• There are a couple of gadgets.window.* API calls that take an optional owner id parameter... it's not clear what exactly these parameters are used for or what functionality they enable due to a complete lack of documentation about them so it's not clear how these would change given this proposal.

Example: Within the gadget instance itself... I could do something like...

...