.

StatusLast UpdatedProposal IdCode ChangeSummaryThread link

.

This is only a structured local copy of the mailing list. It just summarizes everything that has taken place there. See http://groups.google.com/group/opensocial-and-gadgets-spec for more info.Note: the templates discussion is separate from 0.8. It will most likely end up as a feature and not part of the main spec

.

.

OpenSocial related things...

.

Spec agreed upon; 7 + votes, 0 - votes4/28/2008RESTFUL-001http://docs.google.com/View?docid=dc43mmng_2g6k9qzfbAdd support for RESTful urls so that app developers can get data outside of the javascript apis; see also "RESTful details" tab below.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/5b61cef7f36b45c0/29bd8eff3978dafe?lnk=gst&q=RESTful#29bd8eff3978dafe

.

A zillion votes4/20/2008PERSON-001opensocial.Person.Field = {
...
/**
* A boolean indicating whether the person has used the current app.
* @member opensocial.Person.Field
*/
HAS_APP : 'hasApp',
...
}


opensocial.DataRequest.FilterType = {
...
/**
* Retrieves all friends that use this application.
*
* Note: Containers may define "use" in any manner they deem appropriate for
* their functionality, and it is not expected that this field will have the exact
* same semantics across containers
*
* @member opensocial.DataRequest.FilterType
*/
HAS_APP : 'hasApp'
};		Add a new person field called "HAS_APP". If supported by a container and requested by a gadget, will return true if the person has the app installed, and false otherwise.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/9c55f77cdd5873b2#

.

5 Positive Votes5/1/2008REQUEST_SHARE_APP-0011. make an opensocial.NavigationParameters object, fields are "view", "parameters", "owner".
2. add an opt_params parameter to both the requestShareApp and the requestSendMessage methods
3. add two values that will be recognized in the opt_params bucket for both methods = "viewerDestination", "recipientDestination". these will both have type opensocial.NavigationParameters.
4. containers are free to ignore whichever parts of these new optional params they want but of course will make their gadget developers happier if they respect more of the params. this way, orkut doesn't have to change the view if it doesn't want to, but it can still respect the passed in params. on the other hand, hi5 could theoretically respect the view type, but always have viewer = owner (or whatever)		I'd propose we consider for 0.8 the addition on a params field to
requestShareApp, similar to view-params in
gadgets.views.requestNavigateTo.		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/3f257fa792254f4c

.

Closed for 0.8April 30 - didn't get consensusREQUEST_SHARE_APP-002 * @param {Function} opt_callback ... it will be passed a ResponseItem...
* The data on the response item may be set. If there was no error and the
* response item is not null, then it will be an array of person ids
* (Array<String>) indicating which people were successfully asked to use
* the app.
*
* @member opensocial
*/
opensocial.requestShareApp = function(recipients, reason, opt_callback) {};		The 0.7 spec says that no data will be set on the ResponseItem for the
request* calls. Has there been any discussion on adding data to
successful responses? For example, our API servers will return the
following response for a call to send notifications:

{"notification_response":{"sent_ids":1000}}

If we standardized on some sort of similar response we could set the
ResponseItem data field and thereby notify developers which users
actually received their messages, which is something we've had
requests for and is a feature of the FB platform.

Is a standard response for activity and messages part of the REST API
proposal? And if so, is it stable enough for hi5 to implement that
response format for launch?		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/04d654c18fc52c06#

.

Closed for 0.8April 30 - didn't get consensusREQUEST_SEND_MESSAGE-001 * @param {Function} opt_callback ... it will be passed a ResponseItem...
* The data on the response item may be set. If there was no error and the
* response item is not null, then it will be an array of person ids
* (Array<String>) indicating which people were successfully sent
* a message.
*
* @member opensocial
opensocial.requestSendMessage = function(recipients, message, opt_callback) {};		See REQUEST_SHARE_APP-002http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/04d654c18fc52c06#

.

Closed for 0.8April 30 - didn't get consensusREQUEST_CREATE_ACTIVITY-001 * @param {Function} opt_callback ... it will be passed a ResponseItem...
* The data on the response item may be set. If there was no error and the
* response item is not null, then it will be ???????
*
* @member opensocial
opensocial.requestCreateActivity...		See REQUEST_SHARE_APP-002 - what is the response type though?http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/04d654c18fc52c06#

.

5 Positive Votes4/25/2008IS_FRIEND-001opensocial.DataRequest.PeopleRequestFields = {
// profileDetails, sortOrder, filter, etc
...
/**
* Additional options to be passed into the Filter. Specified as a Map<String, Object>.
*/
FILTER_OPTIONS: 'filterOptions'
...
}

opensocial.DataRequest.FilterType = {
// currently just all and hasApp
...
/**
* Will filter the people requested by checking if they are friends with
* the given idSpec. Expects a filterOptions parameter to be passed with the following fields defined:
* - idSpec The idSpec that each person must be friends with.
* - networkDistance An optional parameter, used to specify how long the connection can be for
* two people to be considered friends. Defaults to 1 (they must be the same person or directly be friends). Containers
* can choose which values of this parameter they will support.
* As an example, 2 would mean "friend of a friend".
*/
IS_FRIENDS_WITH: 'isFriendsWith'
}		This issue was raised by a gadget developer

The PhotoAttack app restricts attacking to just friends - this is a wise product choice to avoid spam. Say Abby attacks Bob. Bob gets the attack but before he can attack back, the app needs to check if Abby is still Bob's friend. Currently, the app needs to fetch all of Bob's friends and confirm that Abby is on that list before allowing Bob to attack her back.Fetching all friends (upto 1000) is an expensive operation. So, the ask is to support an IsFriend method.

It seems like this problem can be handled in a number of ways..

1. Implement a DataRequest.newFetchAreFriends(<user spec>,<user spec>, opt_callback)

2. Add support for a filter on DataRequest.newFetchPeopleRequest that computes the intersection of two user specs e.g.
DataRequest.newFetchPeopleRequest(<id spec> , {..., intersect : <id spec>, ...})
This would allow for checking if the viewer was the owner friend by
DataRequest.newFetchPeopleRequest(OWNER_FRIENDS, {..., intersect : VIEWER ...})

In general I think I prefer the 2nd approach as its a more general pattern and has a lower impact on the API. It does however imply a general join facility that may be expense/difficult for containers to implement and enforce quota constraints on.		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/95570a27ab945f6d#

.

5 Positive Votes5/1/2008PERSON-002/**
* @static
* @class
* The enum keys used by the presence field.
* <p><b>See also:</b>
* <a href="opensocial.Person.Field.html">
* opensocial.Person.Field.Presence</a>
* </p>
*
* @name opensocial.Enum.Presence
*/
opensocial.Enum.Presence = {
/**
* The entity or resource is off line.
* @member opensocial.Enum.Presence
*/
OFFLINE : 'OFFLINE',
/**
* The entity or resource is on line.
* @member opensocial.Enum.Presence
*/
ONLINE : 'ONLINE',
/**
* The entity or resource is temporarily away.
* @member opensocial.Enum.Presence
*/
AWAY : 'AWAY',
/**
* The entity or resource is actively interested in chatting.
* @member opensocial.Enum.Presence
*/
CHAT : 'CHAT',
/**
* The entity or resource is busy (dnd = "Do Not Disturb").
* @member opensocial.Enum.Presence
*/
DND : 'DND',
/**
* The entity or resource is away for an extended period
* (xa = "eXtended Away").
* @member opensocial.Enum.Presence
*/
XA : 'XA'
};


/**
* Person's current network status. Specified as an Enum with the enum's
* key referencing opensocial.Enum.Presence.
* Not supported by all containers.
*
* @member opensocial.Person.Field
*/
NETWORK_PRESENCE : 'networkPresence',		Somehow add presence info, maybe an enum, maybe a filter etchttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/75303d2a347ea9f5#

.

5 Positive Votes4/24/2008RESPONSE_ITEM-001opensocial.ResponseItem.Error = {
...

/**
* The gadget passed a quota on the request. Example quotas include a
* max number of calls per day, calls per user per day, calls within a
* certain time period and so forth.
*
* @member opensocial.ResponseItem.Error
*/
LIMIT_EXCEEDED : 'limitExceeded',

...
}		Add a limit exceeded error value to allow developers to treat that scenario differently.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/e58410c6054eec7a

.

Positive Votes5/1/2008DATA_STORE-0011. For 0.8, we change the default type for all app data from String to Json.
2. For 0.9, we can discuss the pros and cons of having explicit types that developers can use. Thankfully, the 0.8 change doesn't prevent this from happening.. it just changes the default type.		Somehow handling json data better in the app data storehttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/4ed634f97029f0cd#

.

5 Positive Votes4/28/2008PERSON-003/**
* @static
* @class
* The enum keys used by the lookingFor field.
* <p><b>See also:</b>
* <a href="opensocial.Person.Field.html">
* opensocial.Person.Field.LookingFor</a>
* </p>
*
* @name opensocial.Enum.LookingFor
*/
opensocial.Enum.LookingFor = {
/** @member opensocial.Enum.LookingFor */
DATING : 'DATING',
/** @member opensocial.Enum.LookingFor */
FRIENDS : 'FRIENDS',
/** @member opensocial.Enum.LookingFor */
RELATIONSHIP : 'RELATIONSHIP',
/** @member opensocial.Enum.LookingFor */
NETWORKING : 'NETWORKING',
/** @member opensocial.Enum.LookingFor */
ACTIVITY_PARTNERS : 'ACTIVITY_PARTNERS',
/** @member opensocial.Enum.LookingFor */
RANDOM : 'RANDOM'
};


/**
* Person's statement about who or what they are looking for, or what they are
* interested in meeting people for. Specified as an Array<Enum> with the enum's
* key referencing opensocial.Enum.LookingFor.
* Not supported by all containers.
*
* @member opensocial.Person.Field
*/
LOOKING_FOR : 'lookingFor',		Make the "interested in" field more structured. http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/6b91c66efbb7ccb1

.

5 Positive VotesApril 124 - 5 votesIDSPEC-0011. Add a new opensocial.IdSpec object.
opensocial.IdSpec = function() {};
opensocial.IdSpec.Field = {
USER_ID : 'userId',
GROUP_ID : 'groupId',
NETWORK_DISTANCE : 'networkDistance',
}
opensocial.IdSpec.prototype.getField = function(key) {};

2. Change all IdSpec references to be opensocial.IdSpec

3. Change the filtering proposal to get rid of the networkDistance param as it is now within the idSpec
Generalize the idSpec model so that we can handle more types of people requests. http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/6b2ba00f8a38cb45

.

7 Positive votesApril 27 - 7 votesFILTER_TYPE-001opensocial.DataRequest.FilterType = {
/**
* Retrieves only the user's top friends.
*
* @member opensocial.DataRequest.FilterType
*/
TOP_FRIENDS : 'topFriends',
...
}		Top friends should be a filter as well as a sorthttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/ae406a39198ecd31

.

5 Positive Votes4/30/2008FETCH_ACTIVITIES-001Get rid of the "activities" pointer in the fetchActivities request
instead of: (datarequest.js line 328)
* When processed, returns an object whose "activities" property is a Collection&lt;Activity&gt; object.
do this:
* When processed, returns an Collection&lt;Activity&gt; object.		get rid of activities pointer on fetch activities and add paginghttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/bfba9d321b5be7d1

.

5 Positive Votes5/1/2008URL_TEMPLATES-001opensocial.getContainerUrlTemplate = function() { ... }

This returns a string containing "${}" variables. The four supported variables are:
- name: the name or id of the application
- owner: the id of the owner of the page
- path: an application-defined path string
- params: application-defined parameters, query-encoded.

Examples of URL template strings:
http://container.com/apps/${name}/${owner}/${path}?${params}
http://apps.container.com/${name}#${path}?${params}
http://container.com/?app=${name}&owner=${owner}&path=${path}&${params}		Gadget developers need real urls and not just js calls in order to make their apps better.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/bfb8c9aaee0ef762

.

5 Positive Votes4/27/2008ESCAPING_DATA-001opensocial.DataRequest.prototype.newFetchPersonAppDataRequest = function(idSpec,
keys, opt_params) {}

plus a new enum...

opensocial.DataRequest.DataRequestFields = {
/**
* An escape type enum specifying whether or not to automatically
* escape all of the data returned. Defaults to true.
*
* @member opensocial.DataRequest.PeopleRequestFields
*/
ESCAPE_VALUES : 'escapeValues',
}

ESCAPE_TYPE:
'htmlEscape', // default value
'none', // use this if you want to enable XSS worms to
attack your users.		Add a flag to turn off auto-escaping of datahttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/974695cf0d0140ff

.

Closed for 0.8April 29 - delayed to 0.9 because it needs a more concrete changePOP_UP-001/**
* Creates a dialog UI that can show the requested other gadget.
*
* @param {string} gadgetUrl URL to gadget spec of the gadget to show in the dialog
* @param {Object} opt_params Various params. Things I imagine:
* width, height, which view to show, is modal or not, params to pass to gadget
*
* @return some object that lets you control the dialog. Show, hide, add listener for its
* closing, get back some kind of return value when it closes, etc.
*/
gadgets.window.createDialog(gadgetUrl, opt_params)		Add a method for gadget developers to make pop ups that the container designs. http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/4056cc17dc9c4499

.

Closed for 0.84/30/2008REQUEST_SEND_MESSAGE-002 * @param {Array<opensocial.Person> || opensocial.IdSpec} recipients An array
* of people or an idSpec indicating who to send the message to.
opensocial.requestSendMessage = function(recipients, message, opt_callback) {};
Change requestSendMessage to take in person objects as well as an idSpechttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/32a59645ba83c8c6

.

Closed for 0.84/30/2008APP_DATA-001newFetchPersonAppDataRequest(idSpec, keys, opt_params)

where opt_params are:

Map<opensocial.DataRequest.PeopleRequestFields.FIRST, opensocial.DataRequest.PeopleRequestFields.MAX>		The app data store should allow paginghttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/62c760430bd15e79

.

Closed for 0.8April 27 - thread closed for 0.8DATA_STORE-002Bring back the global app data storehttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/8493076c6852c13f

.

Closed for 0.8April 27 - thread closed for 0.8DATA_STORE-003newIncrementGlobalAppCounter(id, value) // value can be negative/positive

newUpdateGlobalAppCounter(id, value) // creates counter or forces specific value for counter.

newFetchGlobalAppCounters(ids)

newRemoveGlobalAppCounters(ids) // Removes counter (optional)		Add a global app counter interface for the javascripthttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/e92767d842772ebf

.

5 Positive Votes4/25/2008DATA_STORE-004newRemovePersonAppDataRequest(idSpec, keys)Allow the removal of data from the app data storehttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/e773b11cc5759f34

.

Closed for 0.8April 29 - not enough feedback, delayed to 0.9FETCH_ACTIVITIES-002Add the ability to modify activities shortly after they are createdhttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/2c3a051477efdc28

.

7 Positive votes4/27/2008DATA_RESPONSE-001add dataResponse.getErrorMessage()Add getErrorMessagehttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/6df4c86626f81473

.

Closed for 0.8April 30 - didn't get consensusFEATURE_PARAMS-001getFeatureParameters('opensocial')[ENUM]

Possible enum values:
ActivityTemplate.MaxTitleLength
ActivityTemplate.MaxBodyLength
FetchPeopleRequest.MaxPageSize
ActivityStream.MaxUpdatesPerUserPerDay		Add the ability to query for things like max activity title length. We should be able to do this with the existing method getFeatureParams("opensocial"). But we may want to define some enums you can query for.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/d9bae579dde365f9/

.

Closed for 0.84/30/2008ACTIVITY_TEMPLATES-001Add <em>, <i> and <strong> to the set of accepted tags for activity templates.

Change "has the option to strip out these [HTML] tags" to "has the option to strip out these tags or attributes of these tags".		Current set is {<b>, <i>, <a>, <span>}, container is not obligated to respect any of these tags. Proposal is to add <em> for both title and body and add <br> and <p> for body.

Also want to clarify the requirements around supporting these HTML tags. Currently says that the container "has the option to strip out these [HTML] tags", should change to "has the option to strip out these tags or attributes of these tags".		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/1ca194a76732abe0

.

5 Positive Votes4/27/2008MESSAGES-002Add two new message fields: titleId and bodyId for use with templates. In the docs, activity templates will be renamed message templates and their description will be taken out of the activity.js file.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/a685306537b82803

.

5 Positive Votes4/27/2008MEDIA_ITEMS-001Rename opensocial.Activity.MediaItem to just opensocial.MediaItem. Rename opensocial.newActivityMediaItem to opensocial.newMediaItem.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/a685306537b82803

.

Closed for 0.84/27/2008ACTIVITIES-001Add a min length that containers must support for activity titles. This would just be a doc change. Possibly 160 or 140 characters?http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/f9533d5513d5cd62

.

.

.

.

.

Gadgets related things......

.

5 Positive Votes4/24/2008MODULE_PREFS_SPEC-001<xs:element name="Link">
<xs:complexType>
<xs:attribute name="rel" type="xs:string" use="required"/>
<xs:attribute name="href" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>

Where "gadget help" and "gadget support" would be two rel values that
Orkut would support (and hopefully others).		in orkut, we have need for users to find help and support for apps.

the gadget spec at http://code.google.com/apis/gadgets/docs/reference.html#Moduleprefs_Ref doesn't have these fields. there is author info but i'd imagine most app developers wouldn't want the author_email to be flooded with support issues.

so, the proposal is to add two fields to ModulePrefs:

* <help> - Url to help and FAQ about the app
* <support_URL> - Url to page for users to contact the app about issues
* <support_email> - email address to send mail to		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/c146cb26feb86885#

.

5 Positive Votes4/14/2008MAKE_REQUEST-001 /**
* Fetches content from the provided URL and feeds that content into the
* callback function. If the request is SIGNED will pass the following
* parameters along to the requested Url:
* - opensocial_viewer_id The id of the current viewer, will match the
* getId() value on the viewer person object
* - opensocial_owner_id The id of the current owner, will match the
* getId() value on the owner person object
* - opensocial_app_id The id of the current app
* - xoauth_signature_publickey The oauth for the container's public key
...
*
* @member gadgets.io
*/
makeRequest : function (url, callback, opt_params) {		Containers need to standardize on the post parameters passed to gadget servers when someone has asked for a SIGNED make requesthttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/b07ab79dbcea1afd

.

5 Positive Votes4/25/2008VAR_SUBSTITUTION-0015. Perform substitutions of each hangman expansion on all fields which get displayed to users. This currently includes, but is not limited to, the following fields:
a. All Module.ModulePrefs attributes, Module.Content@href, Module.Content, UserPref@display_name, UserPref@default_value, and UserPref.EnumValue@display_value. 		Allow the expansion of the thumbnail and screenshot module prefs field for internationalization.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/e0b96c2509f2247f#

.

Closed for 0.85/1/2008QUIRKS_MODE-001i. For type HTML gadgets, the order is as follows:

1. Standard HTML header, opening <html> tag and <body> tag. <head> information is optional. Gadgets run the browser mode of the container's choice unless explicitly specified using the "quirks" attribute on the Contents element. If the quirks attribute is set to "true", gadgets will be rendered in quirks mode. If set to "false", they will be rendered in standards mode.

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/fa8e8863f91b6333#

.

Mergedobsolete because of OAUTH-002OAUTH-001<Require feature="oauth">
<Param name="service_name">
demo
</Param>
<Param name="access_url">
http://localhost:9090/oauth-provider/access_token
</Param>
<Param name="access_method">
GET
</Param>

<Param name="request_url">
http://localhost:9090/oauth-provider/request_token
</Param>
<Param name="request_method">
GET
</Param>

<Param name="authorize_url">
http://localhost:9090/oauth-provider/authorize
</Param>
</Require>		a new gadgets feature called "oauth"http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/dfd67adb39f2af6a#

.

5 Positive Votes4/25/2008OAUTH-002The simplest possible OAuth element declares that a gadget will use
OAuth with a service provider that supports OAuth discovery:
<ModulePrefs>
<OAuth>
<Service />
</OAuth>
</ModulePrefs>

OAuth discovery is new, and not many service providers support it yet.
The simplest possible OAuth element for a service provider that does
not support OAuth discovery declares three URLs used during the OAuth
protocol. Several reasonable defaults are assumed for some of the
OAuth protocol details.
<ModulePrefs>
<OAuth>
<Service>
<Request url="http://www.example.com/request"/>
<Authorization url="http://www.example.com/authorize"/>
<Access url="http://www.example.com/access"/>
</Service>
</OAuth>
</ModulePrefs>

The most complex OAuth element declares that the gadget will access
data from multiple OAuth service providers, and declares URLs and
several OAuth protocol details for all of them.
<OAuth>
<Service name="serviceOne">
<Request url="http://www.example.com/request"
method="GET"
param_location="header" />
<Authorization url="http://www.example.com/authorize"
method="GET"
param_location="header" />
<Access url="http://www.example.com/access"
method="GET"
param_location="header" />
</Service>
<Service name="serviceTwo">
<Request url="http://other.example.com/request"
method="GET"
param_location="header" />
<Authorization url="http://other.example.com/authorize"
method="GET"
param_location="header" />
<Access url="http://other.example.com/access"
method="GET"
param_location="header" />
</Service>
</OAuth>

OK, now that there are some examples to show how things ought to look,
let's get normative:

The <ModulePrefs> element can contain 0 or 1 <OAuth> elements.

The <OAuth> element can contain 1 or more <Service> elements.

The <Service> element has a single attribute:
name [optional]. This is a nickname the gadget will use to
reference the service provider. If unspecified, it defaults to "".

The <Service> element contains three elements, a <Request> element, an
<Authorization> element, and an <Access> element.

The <Request> element has three attributes.
url [required]: the absolute URL of the service provider request endpoint.
method [optional]: the HTTP method to use to access the
endpoint. May be GET or POST. If unspecifed, defaults to "GET".
param_location [optional]: the location of the OAuth parameters
in the request. May be "url", "header", or "body". If unspecified,
defaults to "header".

The <Access> element is identical to the <Request> element, but
describes an access token URL instead of a request token URL.

The <Authorization> element has a single attribute:
url [required]: the authorization URL for the service provider.		Instead of having a new oauth feature, the proposal is to put it directly into the gadget xml spec.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/a1ce63eecfb21cad

.

ClosedApril 24 - no spec change really needed, the MODULE_PREFS_SPEC-001 Link proposal solved people's needsFAVICON-001May not need anything... checking
Favicons, link support, href tags?? (thread has wildly diverged)		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/aa2d26d52492ceae

.

MergedMerged into: VIEWS_ATTRIBUTE-004
VIEWS_ATTRIBUTE-001Concat views, only take first view, or version spechttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1856ea093d682c3b#

.

Closed for 0.84/28/2008SCROLLING-001Maybe a new scrolling related feature or gadgets.window method? ... perhaps a long term goalhttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/33c834732265a8a0

.

MergedMerged into: VIEWS_ATTRIBUTE-004
VIEWS_ATTRIBUTE-002Should developers explictly say which views they support? Can we infer that from the xml already? Should the default view say something like "only support this view for promos" etc etchttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/28f6e1d2638a0855

.

Closed for 0.8April 27 - direct thread issue made obsolete by MAKE_REQUEST-004MAKE_REQUEST-002App ids should change to be app urls.. does this only affect makeRequest?http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/a6a981c96685043e

.

5 Positive Votes4/20 - all positiveREQUEST_NAVIGATE_TO-001 * @param {gadgets.views.View} view The view to navigate to
* @param {Map.&lt;String, String&gt;} opt_params Parameters to pass to the
* gadget after it has been navigated to on the surface
* @param {String} opt_ownerId The id of the owner of the page to navigate to.
* Defaults to the current owner.
*/
gadgets.views.requestNavigateTo = function(view, opt_params, opt_ownerId) {};		Add an owner parameter to requestNavigateTohttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/718488b0ea390e73#

.

6 Positive Votes4/27/2008MAKE_REQUEST-003/**
* Fetches content from the provided URL and feeds that content into the
* callback function.
...
If opt_params[gadgets.io.RequestParameters.AUTHORIZATION] is set
to gadgets.io.AuthorizationType.OAUTH:

This indicates that the container needs to use OAuth to gain access to
the resource specified in the request.
This may require that the gadget obtain the user's content by
directing the user to the service provider to gain access.

The following additional parameters may be specified in opt_params:
gadgets.io.RequestParameters.OAUTH_SERVICE_NAME:
The nickname the gadget uses to refer to the OAuth <Service>
element from it's XML spec. If unspecified, defaults to "".

gadgets.io.RequestParameters.OAUTH_TOKEN_NAME:
The nickname the gadget uses to refer to an oauth token granting
access to a particular resources. If unspecified, defaults to "".
Gadgets can use multiple token names if they have access to
multiple resources from the same service provider. For example, a
gadget with access to a contact list and a calendar might use a token
name of "contacts" to use the contact list token, and a contact list
of "calendar" to use the calendar token.

gadgets.io.RequestParameters.OAUTH_REQUEST_TOKEN
A service provider may be able to automatically provision a
gadget with a request token that is preapproved for access to a
resource. The gadget can use that token with the OAUTH_REQUEST_TOKEN
parameter. This parameter is optional.

gadgets.io.RequestParamters.OAUTH_REQUEST_TOKEN_SECRET
The secret corresponding to a preapproved request token. This
parameter is optional.

If OAuth is used, the container should execute the OAuth protocol on
behalf of the gadget. If the gadget has not registered a consumer key
for use with this service provider, the container may choose to use a
default RSA signing key corresponding to a well-known certificate to sign
requests. If the container uses a default consumer key, it will include
an additional OAuth parameter xoauth_app_url that identifies the gadget
making the request.

The makeRequest callback parameter is passed a javascript object with
several OAuth specific fields in addition to the normal values returned
by makeRequest:

"oauthApprovalUrl": if this value is specified, the user needs to
visit an external page to approve the gadget's request to access
data. Use of a pop-up window to direct the user to the external
page is recommended. Once the user has approved access, the gadget
can repeate the makeRequest call to retrieve the data.

"oauthError": if this value is specified, it indicates an OAuth
related error occurred. The value will one of a set of string
constants that can be used for programmatically detecting errors.
The constants are undefined for opensocial-0.8, but implementers
should attempt to agree on a set of useful constant values for
standardization in opensocial-0.9.

"oauthErrorText": if this value is specified, it indicates an
OAuth related error occurred. The value is free-form text that
can be used to provide debugging information for gadget developers.		Add oauth support to makeRequesthttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/92e48a57857ab293

.

5 Positive Votes4/20/2008 - all +1sMESSAGE_BUNDLE-001<Locale lang="en" country="us">
<messagebundle>
<msg name="title">This is the message title.</msg>
</messagebundle>
</Locale>		Allow for message bundles to be flattened inside of the gadget xmlhttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/238d70b7fd080774

.

Closed for 0.85/1/2008CONTENT-001When type=html, href=xxx now has meaning. (Before only for type=url did the href tag have meanng)Allow content data to be specified by a url when using type=htmlhttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/237c992b35c6ce15

.

5 Positive Votes4/27/2008GET_PROXY_URL-001
Change

gadgets.io.getProxyUrl(url)

to

gadgets.io.getProxyUrl(url, opt_params)

Add a new option REFRESH_INTERVAL to control the TTL for proxied
content. Recommend that the default be 1h (3600 seconds)


Add

<static> object REFRESH_INTERVAL

Attempt to use content caching. The Refresh Interval is the number
of seconds we want to cache the given response. The default is 3600
(1 hour). Note that Signed requests and object with POST_DATA
present will generally not be cached.

to gadgets.io.RequestParameters		All getProxyUrl to take in a refreshInterval paramhttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/5ce00ef9ba52f5da

.

5 Positive Votes4/27/2008SANITIZE_HTML-001/**
* Sanitizes a text string. The returned value is safe to assign to innerHTML.
* The returned value may include HTML tags. If plain text is desired, use
* gadgets.util.escapeString instead.
*
* @param {String} text arbitrary text string
* @return {String} a sanitized version that may include HTML tags,
but will not execute script.
*/
function gadgets.util.sanitizeHtml(text) {
...
}		Add a method to sanitize html for a developer.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/fd704f832800c811

.

MergedMerged into: VIEWS_ATTRIBUTE-004
VIEWS_ATTRIBUTE-003Add an "all" type to mean render on all views and change the meaning of "default/no attribute" to mean "only render on default view"http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/b4b7f3493426f78

.

Closed for 0.85/1/2008ESCAPE_STRING-001unescpaeString and escapeString definitions need to be clarified:

Now I don't know if there is a standard for HTML escaping (like for
example the url escaping in RFC3986), but if there is, that should be
used, else we should specify our own behaviour.

unescapeString can then be specified as the inverse function of
escapeString:

unescapeString(escapeString(x)) == x for all x
(in the current Shindig implementation,
unescapeString(escapeString("&amp;")) == "&" )

or could use some standard for unescaping HTML		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/61f07a27560e78c8

.

Closed for 0.8April 28 - you can specify icons by url alreadyICON-001Problem: The current spec allows use of URI's to specify thumbnail
image and screenshot image, but is unclear on whether the icon image
can also be specified via URI.

Proposed Solution: Add a new value of "url" to the "mode" attribute of
the Icon element. In this case, the URI of the icon image would be
included as the value of the Icon element.
Usage: <Icon mode="url">http://foo.bar.bas/myapp/images/icon.jpg</
Icon>		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/8fbf7e97aa82e1cb

.

MergedMerged into: VIEWS_ATTRIBUTE-004
HEIGHT_AND_WIDTH_ATTRIBUTES-001Add preferredHeight and preferredWidth as attributes to the content section.Problem: The current location of the height and with attributes -
under ModulePrefs - makes them effectively global to all content
elements. This doesn't work for OpenSocial apps that have multiple
views, each of which might have different height and width
preferences.

Proposed Solution: As an interim solution to this, we propose adding
optional height and width attributes to the Content element. These
values, if present, would override the global values optionally
specified in ModulePrefs. If multiple Content elements are applicable
to a view (see Concatenation note sent separately) the height/width
values from the last Content element with an exact match of view will
be used. (i.e. not "all, see "all" note sent separately).

.

6 Positive VotesApril 30 - Issues 1,2,4 deferred until 0.9. #3 is approvedVIEWS_ATTRIBUTE-004preferredHeight and preferredWith are new attributes on the content section. they allow per-view default height and width valuesA merge of HEIGHT_AND_WIDTH_ATTRIBUTES-001 and VIEWS_ATTRIBUTE-003, VIEWS_ATTRIBUTE-002, VIEWS_ATTRIBUTE-001. All issues: 1. What does "default" mean. Do we want an "all"?
2. Do we add preferredHeight and preferredWith as attributes to Content?
3. When you have multiple sections with the same view type do you concat or take the first or last? If you concat do you take the attributes from the first or last section?
4. Do we allow comma delimited lists of attributes?
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1845cdb2f3d17777

.

6 Positive Votes4/25/2008PUBSUB_FEATURE-001To publish a string-type message to a channel, a gadget calls:
gadgets.rpc.pubsub.publish(channel_name, message);

To subscribe to a message channel, a gadget calls:
gadgets.rpc.pubsub.subscribe(channel_name, subscriber_callback);
function subscriber_callback(message, sender) {
/* Do something with message if sender is a trusted gadget spec URL. */
}

To unsubscribe from a channel, a gadget calls:
gadgets.rpc.pubsub.unsubscribe(channel_name);

On the container side, the following function must be called to support "pubsub":
gadgets.rpc.pubsub.initializeRouter(gadget_id_to_spec_url_callback, {
onSubscribe: on_subscribe_callback, // optional
onUnsubscribe: on_unsubscribe_callback, // optional
onPublish: on_publish_callback // optional
});
function gadget_id_to_spec_url_callback(gadget_id) {
/* Given a gadget id, return the corresponding gadget spec URL. */
}
function on_subscribe_callback(gadget_id, channel_name) {
/* Return true to reject the subscription request; return false to accept it. */
}
function on_unsubscribe_callback(gadget_id, channel_name) {
/* Return true to reject the unsubscription request; return false to accept it. */
}
function on_publish_callback(gadget_id, channel_name, message) {
/* Return true to discard the message; return false to proceed to broadcast it to the channel. */
}
Add a "pubsub" feature spec. This would be triggered off of "<require feature="pubsub">"http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/f1820dd76cdaceb7

.

8 Positive Votes4/27/2008MAKE_REQUEST-003
/**
* Fetches content from the provided URL and feeds that content into the
* callback function.
...
* If opt_params[gadgets.io.RequestParameters.AUTHORIZATION] is set
to gadgets.io.AuthorizationType.SIGNED:
* This indicates that the container needs to vouch for the user's
identity to the destination server.
* The container will
* - remove any request parameters with names that begin with
oauth, xoauth, or opensocial (ignoring whether the parameter names are
upper or lower case.
* - add the following parameters to the request query string
* opensocial_viewer_id: (optional) The id of the current
viewer, which will match the
* getId() value on the viewer person object.
* opensocial_owner_id: (required) The id of the current
owner, which will match the
* getId() value on the owner person object.
* opensocial_app_url: (required) The URL of the application
making the request. Containers may alias multiple application URLs to
a single canonical application URL in the case where an application
changes URLs.
* opensocial_instance_id: (optional) An opaque identifier
used to distinguish between multiple instances of the same application
in a single container. If a container does not allow multiple
instances of the same application to coexist, this parameter may be
omitted. The combination of opensocial_app_url and
opensocial_instance_id will always uniquely identify an instance of an
application in a container.
* opensocial_app_id: (optional) An opaque identifier for the
application, unique to a particular container. This parameter is
optional. Containers that wish to maintain backwards compatibility
with the opensocial-0.7 specification may include this parameter.
* xoauth_public_key: (optional) An opaque identifier for the
public key used to sign the request. This parameter may be omitted by
containers that do not use public keys to sign requests, or if the
container arranges other means of key distribution with the target of
the request.
* - sign the resulting request according to section 9 of the OAuth
specification (http://oauth.net/core/1.0/#signing_process)
*
* Key management for gadgets.io.AuthorizationType.SIGNED:
*
* If a container uses public keys to sign request, the container may
choose to use either
* self-signed certificates or certificates signed by a well-known
certificate authority.
* If a container does not distribute their oauth signing key over
https, they should use a certificate signed by a well-known
certificate authority.
*
* The commonName attribute of the certificate should match the
hostname of the container server, and should also match the value of
the oauth_consumer_key parameter specified in the request.
*
* The container should make their public key available for download
at a well-known location. The location
* https://<container-hostname>/opensocial/certificates/<xoauth_public_key
value> is recommended.
*
* Recipients of signed requests must verify that the signature on
the request is correct, and that the timestamp on the request is
within a reasonable time window. A time window of +-5 minutes from
the current time is recommended.
*
* Recipients of signed requests may use the oauth_consumer_key and
xoauth_public_key parameters to automatically detect when a container
deploys new certificates. If the container deploys certificates at a
well-known location, the recipient may automatically download the new
certificate. Recipients who automatically download new certificates
should cache the resulting certificates.
*
* If a container's certificate is not downloaded from
https://<container-hostname>, the recipient should verify that the
certificat is signed by a well-known certificate authority before
trusting the certificate.		Clear up some makeRequest signed stuff.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/8e6c33655c06ec6c

.

5 Positive Votes4/28/2008VIEW_TYPES-001Change default view types to be:

- home - private page with possibly multiple apps, viewer=owner
- profile - public page with possibly multiple apps, viewer does not have to = owner
- canvas - public page with a single app, viewer does not have to = owner
- preview - a "demo" page. owner == viewer == null		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/e58410c6054eec7a

.

5 Positive VotesApril 24 - 5 votesPRELOAD-001add the "authz" attribute to the "Preload" element,The authz attribute can be set to "signed" on preload elements to allow developers to say that the preloaded content should be fetched with a signed request.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/8fddcff4534e6e

.

8 Positive Votes4/27/2008LIFECYCLE_EVENTS-001A container may optionally support sending lifecycle events to an
application developer's site by sending relevant query-params to a URL
endpoint. To receive these events you can place one or more link tags
in your app XML. Each link tag has a rel and href attribute. The
href attribute denotes the endpont where event pings are sent. If the
rel attribute is "opensocialevent" then all events are sent to that endpoint.
If the rel attribute matches "opensocialevent.TYPE" then events of TYPE are sent
to that endpoint. An optional method attribute can be set to POST or
GET to specify how the request should be sent. The default is GET.
Here are some examples

<link rel="event" href="http://www.example.com/pingme" method="POST/>
<link rel="event.addapp" href="http://www.example.com/add" />
<link rel="event.removeapp" href="http://www.example.com/remove" />


The following query-params will always be sent to the endpoint:
eventtype - the event type {addapp|removeapp| etc...}

SIGNED parameters will also be sent

[insert signed request verbiage here]

Most events will have information about one or more opensocial ID
values. These id values are passed as one or more id attributes.
Note that a single ping may aggregate a number of events by specifying
many id values.

The following event types are defined. Container custom events should
be designated with a domainname prefix to avoid namespace clashes.

addapp - Users that have installed the app (id)
Optional "from" designates how the user added this
app. Values are "invite", "gallery", "external"

removeapp - IDs of users that have removed the app

app - action={enabled|disabled|approved}
reason={policy|quota|maintenance} [Optional]

invite - id are people invited
from_id is the ID that sent the invitation.		http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/64f588e6daa72b0f