Labs/PAC/Delta - Revision history

Dkettler at 16:40, 14 September 2011

2011-09-14T16:40:35Z

← Older revision		Revision as of 16:40, 14 September 2011
Line 1:		Line 1:
	{{FeatureStatus		{{FeatureStatus
	\|Feature name=Delta		\|Feature name=Delta aka "F2" aka the Streams Mediator
	\|Feature stage=Draft		\|Feature stage=Draft
	\|Feature status=In progress		\|Feature status=In progress

Dkettler at 16:39, 14 September 2011

2011-09-14T16:39:44Z

← Older revision		Revision as of 16:39, 14 September 2011
Line 7:		Line 7:
	{{FeatureTeam}}		{{FeatureTeam}}
	{{FeaturePageBody		{{FeaturePageBody
			\|Feature open issues and risks=* Do we provide our own Activity Stream server?
			* How is caching handled?
	\|Feature overview=It's helpful to be able to control your site-based communications from a single location and allow different sites to access the activities from other sites.		\|Feature overview=It's helpful to be able to control your site-based communications from a single location and allow different sites to access the activities from other sites.

	This feature will provide a way to read from user's various activity streams~~. Posting~~ is already covered by F1, although small modifications may be required to make the two features work well together. ~~For reading, it~~ will provide an API much like F1, adding options for filtering by source site, destination site, author, recipients, content type, priority, time, tags, and possibly others.		This feature will provide a way to read from user's various activity streams (posting is already covered by F1, although small modifications may be required to make the two features work well together). It will provide an API much like F1, adding options for filtering by source site, destination site, author, recipients, content type, priority, time, tags, and possibly others.

	While the intended use of this feature will primarily be application-to-application, it will also trivially allow for a centralized, multi-channel "inbox" of a user's various activity streams (although significant UX work will need to be done to complete this feature if it is desired, as centralized inboxes and aggregators have consistently failed in the market).		While the intended use of this feature will primarily be application-to-application, it will also trivially allow for a centralized, multi-channel "inbox" of a user's various activity streams (although significant UX work will need to be done to complete this feature if it is desired, as centralized inboxes and aggregators have consistently failed in the market).
Line 25:		Line 27:

	The site-based prefs will be implemented in content at an about page (<code>about:streams</code>). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI\|Site-based data management UI]] as appropriate.		The site-based prefs will be implemented in content at an about page (<code>about:streams</code>). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI\|Site-based data management UI]] as appropriate.
	\|Feature implementation ~~notes~~=* ~~no implementation yet.~~		\|Feature implementation plan=* Define API
	* ~~should build off of F1 for communication with social services~~		* Build mediator
			* Build caching protocol
			* Build our server
	}}		}}
	{{FeatureInfo		{{FeatureInfo

Dkettler at 21:12, 1 September 2011

2011-09-01T21:12:25Z

← Older revision		Revision as of 21:12, 1 September 2011
Line 22:		Line 22:
	* Plans for pulling data from streams and caching for responsiveness		* Plans for pulling data from streams and caching for responsiveness
	* API "translators" (so a request to Delta's API makes the correct call to, say, Facebook's API)		* API "translators" (so a request to Delta's API makes the correct call to, say, Facebook's API)
	\|Feature ux design=* ~~coming soon~~		\|Feature ux design=* [http://stanford.edu/~bluenote/hosting/mozilla/delta.png Viewing your feed]

	The site-based prefs will be implemented in content at an about page (<code>about:streams</code>). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI\|Site-based data management UI]] as appropriate.		The site-based prefs will be implemented in content at an about page (<code>about:streams</code>). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI\|Site-based data management UI]] as appropriate.

Dkettler: Created page with "{{FeatureStatus |Feature name=Delta |Feature stage=Draft |Feature status=In progress |Feature health=OK }} {{FeatureTeam}} {{FeaturePageBody |Feature overview=It's helpful to be ..."

2011-09-01T01:27:56Z

Created page with "{{FeatureStatus |Feature name=Delta |Feature stage=Draft |Feature status=In progress |Feature health=OK }} {{FeatureTeam}} {{FeaturePageBody |Feature overview=It's helpful to be ..."

New page

{{FeatureStatus
|Feature name=Delta
|Feature stage=Draft
|Feature status=In progress
|Feature health=OK
}}
{{FeatureTeam}}
{{FeaturePageBody
|Feature overview=It's helpful to be able to control your site-based communications from a single location and allow different sites to access the activities from other sites.

This feature will provide a way to read from user's various activity streams. Posting is already covered by F1, although small modifications may be required to make the two features work well together. For reading, it will provide an API much like F1, adding options for filtering by source site, destination site, author, recipients, content type, priority, time, tags, and possibly others.

While the intended use of this feature will primarily be application-to-application, it will also trivially allow for a centralized, multi-channel "inbox" of a user's various activity streams (although significant UX work will need to be done to complete this feature if it is desired, as centralized inboxes and aggregators have consistently failed in the market).
|Feature users and use cases=* For consumers, provide a centralized access point for a user's activity streams across various sites
* For consumers, empower users to control these access relationships, connecting streams as they see fit
* For developers, provide a way to publicize a user's activity in your app
* For developers, Provide a way to pull down activity relevant to a user and to your app for in-app presentation of social activity
|Feature requirements=* We need to document existing stream data sources and APIs to make a natural and comprehensible API for developers
* These API and data type definitions will drive mappings to the user interface
* UI for both configuration and use must be designed carefully and with user studies
* Security and authenticity of the configuration UI must be verified and accessible to users.
* Plans for pulling data from streams and caching for responsiveness
* API "translators" (so a request to Delta's API makes the correct call to, say, Facebook's API)
|Feature ux design=* coming soon

The site-based prefs will be implemented in content at an about page (<code>about:streams</code>). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the [[Privacy/Features/Site-based_data_management_UI|Site-based data management UI]] as appropriate.
|Feature implementation notes=* no implementation yet.
* should build off of F1 for communication with social services
}}
{{FeatureInfo
|Feature priority=Unprioritized
}}
{{FeatureTeamStatus}}