ACLs on setAppData

[Brian Eaton]

[changing subject to increase visibility]

I agree with Evan that we need a private per-user store of data. The
current situation with access control for appdata is very muddy and
leads to a gadget that is safe on one container being dangerous to use
on other containers.

To be blunt, I think that the appdata specification does not describe
who can read/write the data is a bug. I know the intention was to be
flexible, but it ended up just being vague.

2009/2/12 Evan Gilbert <uid...@google.com>:
> I think we need a private per-user store of data.
>
> If we deprecate User Prefs, we should probably add an ACL flag to app data,
> similar to an earlier proposal I made @
> http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/4fdfe6f95ef6bcd5
>
> This requires adding a single optional field to all setAppData calls.
>
> Evan
>
> 2009/2/12 Adam Winer <awi...@gmail.com>
>>
>> I'm personally +1000 for that - I'm unaware, for example, of any
>> gadgets whatsoever in Orkut that use preferences - but would want to
>> hear from a wider range of developers before we committed to that
>> path.
>>
>> 2009/2/12 Scott Seely <sSe...@myspace.com>:
>> >
>> > Well, then I'd like to change this discussion and instead suggest that
>> > all references to UserPreferences get removed from REST 0.9. This should be
>> > a non-breaking change as UserPreferences didn't exist prior to this
>> > iteration.
>> >
>> > (and yeah, I'm well aware I introduced the idea originally.)
>> >
>> > Should we follow with Pan's idea and deprecate gadgets.Prefs?
>> >
>> >> -----Original Message-----
>> >> From: opensocial-an...@googlegroups.com
>> >> [mailto:opensocial-and-
>> >> gadget...@googlegroups.com] On Behalf Of Adam Winer
>> >> Sent: Thursday, February 12, 2009 9:54 AM
>> >> To: opensocial-an...@googlegroups.com
>> >> Cc: Pan Jie(潘劼)
>> >> Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs for REST
>> >> API
>> >>
>> >>
>> >> User Preferences is a legacy feature from the old iGoogle gadgets
>> >> days, with a legacy and rather odd API. AppData is its replacement.
>> >>
>> >> 2009/2/12 Scott Seely <sSe...@myspace.com>:
>> >> > The URL limitation is a red herring—you can upload the info as JSON
>> >> > or
>> >> XML
>> >> > in the body of the request via a PUT or POST.
>> >> >
>> >> >
>> >> >
>> >> > Can someone maybe explain why we do have both AppData and
>> >> UserPreferences?
>> >> > As Pan points out, they are essentially the same thing.
>> >> >
>> >> >
>> >> >
>> >> > From: Pan Jie(潘劼) [mailto:pan...@google.com]
>> >> > Sent: Thursday, February 12, 2009 12:28 AM
>> >> > To: Scott Seely
>> >> > Cc: opensocial-an...@googlegroups.com
>> >> > Subject: Re: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs
>> >> > for
>> >> REST
>> >> > API
>> >> >
>> >> >
>> >> >
>> >> > Hi, Scott,
>> >> >
>> >> >
>> >> >
>> >> > Sorry for slow response.
>> >> >
>> >> >
>> >> >
>> >> > Shindig can support tracing type for each preference. But before
>> >> > implementing, I am still confusing about the design of setprefs
>> >> > feature.
>> >> I
>> >> > would like to propose removing setArray method from gadgets.Prefs.
>> >> >
>> >> >
>> >> >
>> >> > All user preference will be constructed as url parameter when
>> >> > processing
>> >> > gadget rendering request. Url parameter looks like
>> >> > "&up_key1=value1&up_key2=value2".
>> >> >
>> >> > There are many caveats here.
>> >> >
>> >> >
>> >> >
>> >> > 1. Each key/value pair should be encoded before url constructing and
>> >> decoded
>> >> > after passing to gadget.
>> >> >
>> >> > Currently orkut/igoogle don't support "string with space" as
>> >> > ksy/value of
>> >> > user prefs. Partuza will translate "string with space" to
>> >> > "string+with+space" and won't decode when passing it to gadgets.
>> >> > MySpace
>> >> > doesn't support setprefs feature right now.
>> >> >
>> >> >
>> >> >
>> >> > 2.Considerate of setArray, it is more complicated.
>> >> >
>> >> > Shindig implements setArray like this: value ["value1", "value2",
>> >> > "value|with|seperator"] will be stringified to
>> >> > "value1|value2|value%7cwith%7cseperator". (You can find code in my
>> >> > last
>> >> > email.) Since there are a few bugs for setArray in Shindig, I don't
>> >> > think
>> >> > there are any containers which support setArray right now.
>> >> >
>> >> > Now, opensocial spec supports array of string/number. Should we
>> >> > support
>> >> > array of array? If so, we need not only trace type for preference,
>> >> > but
>> >> also
>> >> > trace type for every element once the preference is an array.
>> >> >
>> >> >
>> >> >
>> >> > 3. Url length limitation is about 2k bytes.
>> >> >
>> >> > Most explorer/http lib will cut url at about 2k bytes. So we can't
>> >> > using
>> >> > user prefs to store much information. Alternatively, apps data is a
>> >> better
>> >> > place.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > 2009/2/11 Scott Seely <sSe...@myspace.com>
>> >> >
>> >> > MySpace doesn't have this implementation issue. We actually track the
>> >> type
>> >> > of item that was added so that we can easily reconstitute the item
>> >> > with
>> >> the
>> >> > correct type. I agreed with the notion of not storing
>> >> > number/bool/string
>> >> > type because it is fairly normal for JS applications to convert from
>> >> > typeàstringàtype. Likewise, the XML parser needs to know how to
>> >> > convert
>> >> > stringàtype Arrays are always arrays. It seems that we can continue
>> >> > to
>> >> > achieve that in OpenSocial with a natural encoding. This is a case
>> >> > where
>> >> I
>> >> > think the container should make things easier for the consumer. In
>> >> > JSON,
>> >> you
>> >> > had a workaround that was sensible because you control the JS. In
>> >> > REST,
>> >> the
>> >> > only location to inject this helper is at the REST service.
>> >> >
>> >> >
>> >> >
>> >> > Keep in mind that our consumers will be Ruby, PHP, and other
>> >> applications.
>> >> > We may not see as much JavaScript with REST.
>> >> >
>> >> >
>> >> >
>> >> > From: Pan Jie(潘劼) [mailto:pan...@google.com]
>> >> > Sent: Tuesday, February 10, 2009 12:11 AM
>> >> >
>> >> > To: Scott Seely
>> >> > Cc: opensocial-an...@googlegroups.com
>> >> > Subject: Re: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs
>> >> > for
>> >> REST
>> >> > API
>> >> >
>> >> >
>> >> >
>> >> > Hi, Scott,
>> >> >
>> >> >
>> >> >
>> >> > For shindig implementation, all arrays are stored as string.
>> >> >
>> >> > "favoriteColors": [ "blue", "red"] will be stored as key
>> >> > "favoriteColors"
>> >> > and value "blue|red".
>> >> >
>> >> >
>> >> >
>> >> > You can find code
>> >> > here:
>> >>
>> >> http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/setprefs/s
>> >> etprefs.js
>> >> >
>> >> > /**
>> >> >
>> >> > * Stores a preference from the given list.
>> >> >
>> >> > * @param {String} key The pref to store.
>> >> >
>> >> > * @param {Array.<String | Number>} val The values to store.
>> >> >
>> >> > * @private This feature is documented in prefs.js
>> >> >
>> >> > */
>> >> >
>> >> > gadgets.Prefs.prototype.setArray = function(key, val) {
>> >> >
>> >> > // We must escape pipe (|) characters to ensure that decoding in
>> >> >
>> >> > // getArray actually works properly.
>> >> >
>> >> > for (var i = 0, j = val.length; i < j; ++i) {
>> >> >
>> >> > val[i] = val[i].replace(/\|/g, "%7C");
>> >> >
>> >> > }
>> >> >
>> >> > gadgets.Prefs.setInternal_(key, val.join('|'));
>> >> >
>> >> > };
>> >> >
>> >> > In this case, server don't know whether "blue|red" is a string or an
>> >> array.
>> >> > It's the same with int/float.
>> >> >
>> >> >
>> >> >
>> >> > I think it is better not to use setArray. If we want to save arrays,
>> >> > we
>> >> can
>> >> > use prefs.set(key, gadgets.json.stringify(value)).
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Feb 10, 2009 at 5:17 AM, Scott Seely <sSe...@myspace.com>
>> >> > wrote:
>> >> >
>> >> > Pan―Can you comment on this patch?
>> >> >
>> >> >
>> >> >
>> >> > Can someone from shindig/other implementations take a look and see if
>> >> this
>> >> > change to the spec is OK?
>> >> >
>> >> >
>> >> >
>> >> > From: opensocial-an...@googlegroups.com
>> >> > [mailto:opensocial-an...@googlegroups.com] On Behalf Of
>> >> > Scott
>> >> > Seely
>> >> > Sent: Wednesday, February 04, 2009 1:21 PM
>> >> > To: Pan Jie(潘劼); opensocial-an...@googlegroups.com
>> >> >
>> >> > Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs for
>> >> > REST
>> >> API
>> >> >
>> >> >
>> >> >
>> >> > Thanks to Pan for pushing this a month ago and not letting it lie.
>> >> >
>> >> >
>> >> >
>> >> > I've rolled up his feedback with that of a few others. The main
>> >> difference
>> >> > is that the JSON and XML/Atom models are much more concise. We are
>> >> assuming
>> >> > that code consuming the values knows whether or not the value should
>> >> > be
>> >> > interpreted as a bool/enum/string/number/array. As such, preserving
>> >> > type
>> >> > info has no utility. This allows for a significant simplification of
>> >> > the
>> >> > representation. The patch updates the representation, the service
>> >> > info,
>> >> and
>> >> > the schema (also contained in the attached patch):
>> >> >
>> >> >
>> >> >
>> >> > Update to section 3.6
>> >> >
>> >> > application/json representation:
>> >> >
>> >> >
>> >> >
>> >> > {
>> >> >
>> >> > "lang": "en",
>> >> >
>> >> > "country": "US",
>> >> >
>> >> > "moduleId": "24341",
>> >> >
>> >> > "favoriteColors": [ "blue", "red"],
>> >> >
>> >> > "boolVal1": "true",
>> >> >
>> >> > "millisecondsOnline": "1234567",
>> >> >
>> >> > "pi": "3.14159",
>> >> >
>> >> > "stringVal1": "hi",
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > application/xml representation:
>> >> >
>> >> >
>> >> >
>> >> > <userPreferences xmlns="http://ns.opensocial.org/2008/opensocial">
>> >> >
>> >> > <lang>en</lang>
>> >> >
>> >> > <country>US</country>
>> >> >
>> >> > <moduleId>24341</moduleId>
>> >> >
>> >> > <favoriteColors>
>> >> >
>> >> > <entry>blue</entry>
>> >> >
>> >> > <entry>red</entry>
>> >> >
>> >> > </favoriteColors>
>> >> >
>> >> > <boolVal1>true</boolVal1>
>> >> >
>> >> > <millisecondsOnline>1234567</millisecondsOnline>
>> >> >
>> >> > <pi>3.14159</pi>
>> >> >
>> >> > <stringVal1>hi</stringVal1>
>> >> >
>> >> > </userPreferences>
>> >> >
>> >> > application/atom+xml representation:
>> >> >
>> >> >
>> >> >
>> >> > <entry xmlns="http://www.w3.org/2005/Atom">
>> >> >
>> >> > <content type="application/xml">
>> >> >
>> >> > <userPreferences
>> >> > xmlns="http://ns.opensocial.org/2008/opensocial">
>> >> >
>> >> > <lang>en</lang>
>> >> >
>> >> > <country>US</country>
>> >> >
>> >> > <moduleId>24341</moduleId>
>> >> >
>> >> > <favoriteColors>
>> >> >
>> >> > <entry>blue</entry>
>> >> >
>> >> > <entry>red</entry>
>> >> >
>> >> > </favoriteColors>
>> >> >
>> >> > <boolVal1>true</boolVal1>
>> >> >
>> >> > <millisecondsOnline>1234567</millisecondsOnline>
>> >> >
>> >> > <pi>3.14159</pi>
>> >> >
>> >> > <stringVal1>hi</stringVal1>
>> >> >
>> >> > </userPreferences>
>> >> >
>> >> > </content>
>> >> >
>> >> > <title/>
>> >> >
>> >> > <updated>2003-12-13T18:30:02Z</updated>
>> >> >
>> >> > <author>
>> >> >
>> >> > <url>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</url>
>> >> >
>> >> > </author>
>> >> >
>> >> > <id>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</id>
>> >> >
>> >> > </entry>
>> >> >
>> >> >
>> >> >
>> >> > Update to Section 7.5
>> >> >
>> >> > 7.5 UserPreferences
>> >> >
>> >> > XRDS Type: http://ns.opensocial.org/2008/opensocial/userpreferences
>> >> >
>> >> > URI structure: {guid}
>> >> >
>> >> > guid: Container-globally-unique user identifier or @me to indicate
>> >> > the
>> >> > requestor should be used.
>> >> >
>> >> > App ID is always mapped using the OAuth parameters.
>> >> >
>> >> > UserPreferences reserves the following field names:
>> >> >
>> >> > country: Gets the current country, returned as an ISO 3166-1 alpha-2
>> >> code.
>> >> > lang: Gets the language to use when communicating with the user,
>> >> > returned
>> >> as
>> >> > an ISO 639-1 code.
>> >> > moduleId: Gets the module ID for the current application instance.
>> >> >
>> >> > When no fields= filter is present in the query string, all
>> >> > preferences
>> >> for
>> >> > the {guid} and {appid} are returned.
>> >> >
>> >> > User Preferences URI examples:
>> >> >
>> >> > URI Fragment
>> >> >
>> >> > Description
>> >> >
>> >> > /userpreferences/@me
>> >> >
>> >> > Returns all preferences for the current user.
>> >> >
>> >> > /userpreferences/@me?fields=avatar,backgroundColor
>> >> >
>> >> > Returns the avatar and backgroundColor values.
>> >> >
>> >> >
>> >> >
>> >> > Update to schema:
>> >> >
>> >> > <xs:complexType name="UserPreferences">
>> >> >
>> >> > <xs:choice minOccurs="0">
>> >> >
>> >> > <xs:element minOccurs="0" name="lang" type="xs:string" />
>> >> >
>> >> > <xs:element minOccurs="0" name="country" type="xs:string" />
>> >> >
>> >> > <xs:element minOccurs="0" name="moduleId" type="xs:string" />
>> >> >
>> >> > <xs:any minOccurs="0" maxOccurs="unbounded"/>
>> >> >
>> >> > </xs:choice>
>> >> >
>> >> > </xs:complexType>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > From: Pan Jie(潘劼) [mailto:pan...@google.com]
>> >> > Sent: Saturday, January 31, 2009 11:41 AM
>> >> > To: Scott Seely
>> >> > Cc: opensocial-an...@googlegroups.com
>> >> > Subject: Re: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs
>> >> > for
>> >> REST
>> >> > API
>> >> >
>> >> >
>> >> >
>> >> > + opensocial-and-gadgets-spec
>> >> >
>> >> > Hi, Scott,
>> >> >
>> >> >
>> >> >
>> >> > It looks good to me. I think PHP Shindig would support this.
>> >> >
>> >> >
>> >> >
>> >> > On Sat, Jan 31, 2009 at 4:21 AM, Scott Seely <sSe...@myspace.com>
>> >> > wrote:
>> >> >
>> >> > Pan,
>> >> >
>> >> >
>> >> >
>> >> > I worked with our internal devs and they are buying this argument now
>> >> too.
>> >> > Now that they've bought this idea, they've pushed a bit further, to
>> >> > this:
>> >> >
>> >> >
>> >> >
>> >> > <userPreferences xmlns="http://ns.opensocial.org/2008/opensocial">
>> >> >
>> >> > <lang>en</lang>
>> >> >
>> >> > <country>US</country>
>> >> >
>> >> > <moduleId>24341</moduleId>
>> >> >
>> >> > <startingCredits>1234</startingCredits>
>> >> >
>> >> > <myArray>
>> >> >
>> >> > <entry>123</entry>
>> >> >
>> >> > <entry>blue</entry>
>> >> >
>> >> > <entry>false</entry>
>> >> >
>> >> > </myArray>
>> >> >
>> >> > </userPreferences>
>> >> >
>> >> > {
>> >> >
>> >> > 'startingCredits':'1234',
>> >> >
>> >> > 'myArray':['123', 'blue', 'true']
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > Is this something that Google would support?
>> >> >
>> >> >
>> >> >
>> >> > From: Pan Jie(潘劼) [mailto:pan...@google.com]
>> >> > Sent: Friday, January 30, 2009 7:45 AM
>> >> > To: Scott Seely
>> >> > Subject: Re: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs
>> >> > for
>> >> REST
>> >> > API
>> >> >
>> >> >
>> >> >
>> >> > Hi, Scott,
>> >> >
>> >> >
>> >> >
>> >> > In my opinion, all values should be treated as string on server side.
>> >> Client
>> >> > side should know concrete types for each key/value pair.
>> >> >
>> >> >
>> >> >
>> >> > prefs.set('startingCredits', 1234); // stores an int or float
>> >> >
>> >> >
>> >> >
>> >> > Server doesn't know whether 1234 is an integer or a float. Server
>> >> > should
>> >> > store a key/value pair 'startingCredits'/'1234' to database.
>> >> >
>> >> > And the result for UserPrefs REST call should be:
>> >> >
>> >> > <userPreferences xmlns="http://ns.opensocial.org/2008/opensocial">
>> >> >
>> >> > <lang>en</lang>
>> >> >
>> >> > <country>US</country>
>> >> >
>> >> > <moduleId>24341</moduleId>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>startingCredits</key>
>> >> >
>> >> > <value>1234</value>
>> >> >
>> >> > </entry>
>> >> >
>> >> > </userPreferences>
>> >> >
>> >> > {
>> >> >
>> >> > 'startingCredits' : '1234'
>> >> >
>> >> > }
>> >> >
>> >> > On Fri, Jan 30, 2009 at 9:32 PM, Scott Seely <sSe...@myspace.com>
>> >> > wrote:
>> >> >
>> >> > Pan,
>> >> >
>> >> >
>> >> >
>> >> > We've been revisiting this discussion at MySpace. We'd like to push
>> >> > for
>> >> an
>> >> > implementation that looks more like what is shown below. Are you
>> >> interested
>> >> > in collaborating on this still?
>> >> >
>> >> >
>> >> >
>> >> > <userPreferences xmlns="http://ns.opensocial.org/2008/opensocial">
>> >> >
>> >> > <lang>en</lang>
>> >> >
>> >> > <country>US</country>
>> >> >
>> >> > <moduleId>24341</moduleId>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>favoriteColors</key>
>> >> >
>> >> > <array>
>> >> >
>> >> > <string>blue</string>
>> >> >
>> >> > <string>red</string>
>> >> >
>> >> > </array>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>statusMessages</key>
>> >> >
>> >> > <array>
>> >> >
>> >> > <string>online</string>
>> >> >
>> >> > <string>offline</string>
>> >> >
>> >> > </array>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>boolVal1</key>
>> >> >
>> >> > <bool >true</bool>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>boolVal2</key>
>> >> >
>> >> > <bool >false</bool>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>millisecOnline</key>
>> >> >
>> >> > <number>1234567</number>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>highScore</key>
>> >> >
>> >> > <number>8600</number>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>e</key>
>> >> >
>> >> > <number>2.71828</number>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key>pi</key>
>> >> >
>> >> > <number>3.14159</number>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key> stringVal1</key>
>> >> >
>> >> > <string>hi</string>
>> >> >
>> >> > </entry>
>> >> >
>> >> > <entry>
>> >> >
>> >> > <key> stringVal2</key>
>> >> >
>> >> > <string>bye</string>
>> >> >
>> >> > </entry>
>> >> >
>> >> > </userPreferences>
>> >> >
>> >> >
>> >> >
>> >> > {
>> >> >
>> >> > "lang": "en",
>> >> >
>> >> > "country": "US",
>> >> >
>> >> > "moduleId": "24341",
>> >> >
>> >> > "favoriteColors": [ "blue", "red"],
>> >> >
>> >> > "statusMessages": [ "online", "offline"],
>> >> >
>> >> > "topSellers": [45646, 456265],
>> >> >
>> >> > "boolVal1": true,
>> >> >
>> >> > "boolVal2":false,
>> >> >
>> >> > "millisecondsOnline": 1234567,
>> >> >
>> >> > "highScore": 8600,
>> >> >
>> >> > "e": 2.71828,
>> >> >
>> >> > "pi": 3.14159,
>> >> >
>> >> > "stringVal1": "hi",
>> >> >
>> >> > "stringVal2": "bye"
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > From: opensocial-an...@googlegroups.com
>> >> > [mailto:opensocial-an...@googlegroups.com] On Behalf Of
>> >> > Pan
>> >> > Jie(??)
>> >> >
>> >> > Sent: Thursday, January 08, 2009 4:01 AM
>> >> >
>> >> > To: opensocial-an...@googlegroups.com
>> >> > Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs for
>> >> > REST
>> >> API
>> >> >
>> >> >
>> >> >
>> >> > I'm implementing UserPrefs REST API for php Shindig.
>> >> >
>> >> >
>> >> >
>> >> > There are two bunches of data types for user preferences:
>> >> >
>> >> >
>> >> >
>> >> > 1. gadgets xsd:
>> >> >
>> >> > http://code.google.com/p/opensocial-
>> >> resources/source/browse/spec/0.8/gadgets/gadgets-extended.xsd
>> >> >
>> >> > in line 153, data types are: string, hidden, bool, enum, list,
>> >> > number,
>> >> > location
>> >> >
>> >> > <xs:attribute name="datatype" default="string">
>> >> >
>> >> > <xs:simpleType>
>> >> >
>> >> > <xs:restriction base="xs:string">
>> >> >
>> >> > <xs:enumeration value="string"/>
>> >> >
>> >> > <xs:enumeration value="hidden"/>
>> >> >
>> >> > <xs:enumeration value="bool"/>
>> >> >
>> >> > <xs:enumeration value="enum"/>
>> >> >
>> >> > <xs:enumeration value="list"/>
>> >> >
>> >> > <xs:enumeration value="number"/>
>> >> >
>> >> > <xs:enumeration value="location"/>
>> >> >
>> >> > </xs:restriction>
>> >> >
>> >> > </xs:simpleType>
>> >> >
>> >> >
>> >> >
>> >> > 2. gadgets api:
>> >> > http://sites.google.com/site/opensocialdraft/Home/gadgets-api-
>> >> specification/gadgets-prefs
>> >> >
>> >> > methods are: getString, getInt, getFloat, getBool, getArray
>> >> >
>> >> >
>> >> >
>> >> > shindig/features/core/prefs.js use parseInt/parseFloat for number
>> >> > data.
>> >> >
>> >> >
>> >> >
>> >> > The javascript api implies that gadget author should know what type
>> >> > is
>> >> for
>> >> > each UserPrefs. So gadget author will choose right method from
>> >> > getString/getInt/getFloat. So I think data type for key is useless. I
>> >> > suggest not returning data types in response of REST api. Instead, we
>> >> > can
>> >> > just return key/value pairs and lang/country/moduleId.
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Jan 7, 2009 at 4:26 AM, Scott Seely <sSe...@myspace.com>
>> >> > wrote:
>> >> >
>> >> > While implementing the spec, we've come across a minor issue in
>> >> UserPrefs.
>> >> > The API calls for intValues and floatValues where the actual gadget
>> >> > XML
>> >> only
>> >> > stores numbers. The UserPrefs item needs to coalesce intValues and
>> >> > floatValues into numberValues. If I hear no dissent, I'll update the
>> >> > spec
>> >> > accordingly tomorrow AM.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: opensocial-an...@googlegroups.com
>> >> >> [mailto:opensocial-
>> >> and-
>> >> >> gadget...@googlegroups.com] On Behalf Of Scott Seely
>> >> >> Sent: Monday, November 03, 2008 2:30 PM
>> >> >> To: opensocial-an...@googlegroups.com
>> >> >> Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs for
>> >> >> REST
>> >> >> API
>> >> >>
>> >> >>
>> >> >> This update has been applied to
>> >> >> http://sites.google.com/site/opensocialdraft/Home/restful-protocol-
>> >> >> specification.
>> >> >>
>> >> >> > -----Original Message-----
>> >> >> > From: opensocial-an...@googlegroups.com
>> >> >> > [mailto:opensocial-
>> >> >> > and-gadg...@googlegroups.com] On Behalf Of Scott Seely
>> >> >> > Sent: Monday, November 03, 2008 2:04 PM
>> >> >> > To: opensocial-an...@googlegroups.com
>> >> >> > Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs for
>> >> REST
>> >> >> > API
>> >> >> >
>> >> >> >
>> >> >> > That 5 +1 and no -1. Unless we see any negative comments, this is
>> >> being
>> >> >> > promoted to the spec.
>> >> >> >
>> >> >> > > -----Original Message-----
>> >> >> > > From: opensocial-an...@googlegroups.com
>> >> >> > [mailto:opensocial-
>> >> >> > > and-gadg...@googlegroups.com] On Behalf Of Maxwell Newbould
>> >> >> > > Sent: Monday, November 03, 2008 2:01 PM
>> >> >> > > To: opensocial-an...@googlegroups.com
>> >> >> > > Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs
>> >> >> > > for
>> >> >> > REST
>> >> >> > > API
>> >> >> > >
>> >> >> > >
>> >> >> > > +1
>> >> >> > >
>> >> >> > > -----Original Message-----
>> >> >> > > From: opensocial-an...@googlegroups.com
>> >> >> > [mailto:opensocial-
>> >> >> > > and-gadg...@googlegroups.com] On Behalf Of Scott Seely
>> >> >> > > Sent: Monday, November 03, 2008 9:28 AM
>> >> >> > > To: OpenSocial - OpenSocial and Gadgets Specification Discussion
>> >> >> > > Subject: [opensocial-and-gadgets-spec] Re: Proposal: UserPrefs
>> >> >> > > for
>> >> >> > REST
>> >> >> > > API
>> >> >> > >
>> >> >> > >
>> >> >> > > We have 4 +1 votes on this idea. The primary beneficiary of the
>> >> >> > > UserPrefs RESTful API is a non-JavaScript application such as
>> >> >> > > ActionScript or Silverlight.
>> >> >> > >
>> >> >> > > Can we have any disagreements pop up soon or get that last +1
>> >> >> > > vote?
>> >> >> > >
>> >> >> > > On Nov 1, 2:19 am, Chris Chabot <chab...@google.com> wrote:
>> >> >> > > > +1 from me too
>> >> >> > > >
>> >> >> > > > On Mon, Oct 27, 2008 at 12:39 PM, Scott Seely
>> >> >> > > > <sse...@myspace.com>
>> >> >> > > wrote:
>> >> >> > > >
>> >> >> > > > > We have 3 +1 votes on this. Do we have any other concerns?
>> >> >> > > >
>> >> >> > > > > On Oct 20, 1:36 pm, "Bob Evans" <bobev...@google.com> wrote:
>> >> >> > > > > > Good answers.
>> >> >> > > >
>> >> >> > > > > > +1
>> >> >> > > >
>> >> >> > > > > > On Fri, Oct 17, 2008 at 7:47 AM, Scott Seely
>> >> >> > <sSe...@myspace.com>
>> >> >> > > wrote:
>> >> >> > > >
>> >> >> > > > > > > Great question. MySpace is adding support for UserPrefs
>> >> >> > > > > > > in
>> >> >> > > gadgets. As
>> >> >> > > > > > > part of this work, we had to support on our servers to
>> >> >> > > > > > > allow
>> >> >> > > the
>> >> >> > > > > gadgets
>> >> >> > > > > > > JS API to work. While writing this code, we saw that the
>> >> >> > server
>> >> >> > > side
>> >> >> > > > > > > wasn't spec'd. We felt that there is benefit in
>> >> >> > > > > > > specifying
>> >> >> > how
>> >> >> > > > > > > UserPrefs would work for REST since most/all containers
>> >> >> > > > > > > will
>> >> >> > > need to
>> >> >> > > > > > > send the UserPrefs back to the server from the JS API in
>> >> some
>> >> >> > > manner.
>> >> >> > > > > > > Giving this support to REST apps costs nothing other
>> >> >> > > > > > > than
>> >> >> > > > > > > standardization and allows apps to get the settings as
>> >> >> > > > > > > they
>> >> >> > > need.
>> >> >> > > >
>> >> >> > > > > > > -----Original Message-----
>> >> >> > > > > > > From: opensocial-an...@googlegroups.com
>> >> >> > > > > > > [mailto:opensocial-an...@googlegroups.com] On
>> >> >> > Behalf
>> >> >> > > Of Bob
>> >> >> > > > > > > Evans
>> >> >> > > > > > > Sent: Thursday, October 16, 2008 6:07 PM
>> >> >> > > > > > > To: opensocial-an...@googlegroups.com
>> >> >> > > > > > > Subject: [opensocial-and-gadgets-spec] Re: Proposal:
>> >> >> > UserPrefs
>> >> >> > > for REST
>> >> >> > > > > > > API
>> >> >> > > >
>> >> >> > > > > > > Yes, that is correct.
>> >> >> > > >
>> >> >> > > > > > > My question was do we really want that or is it just for
>> >> >> > > parity's
>> >> >> > > > > > > sake. Will consumers of REST want to store userprefs? I
>> >> would
>> >> >> > > expect
>> >> >> > > > > > > they would store those sorts of things on their side.
>> >> >> > > >
>> >> >> > > > > > > Bob
>> >> >> > > >
>> >> >> > > > > > > On Thu, Oct 16, 2008 at 7:43 AM, Scott Seely
>> >> >> > > <sSe...@myspace.com>
>> >> >> > > > > wrote:
>> >> >> > > >
>> >> >> > > > > > >> The start of this thread contains a proposal to map
>> >> >> > UserPrefs
>> >> >> > > into
>> >> >> > > > > > > REST.
>> >> >> > > > > > >> At this point, we don't have a parallel structure in
>> >> >> > > > > > >> REST.
>> >> >> > > >
>> >> >> > > > > > >> -----Original Message-----
>> >> >> > > > > > >> From: opensocial-an...@googlegroups.com
>> >> >> > > > > > >> [mailto:opensocial-an...@googlegroups.com]
>> >> >> > > > > > >> On
>> >> >> > > Behalf Of
>> >> >> > > > > Bob
>> >> >> > > > > > >> Evans
>> >> >> > > > > > >> Sent: Wednesday, October 15, 2008 4:52 PM
>> >> >> > > > > > >> To: opensocial-an...@googlegroups.com
>> >> >> > > > > > >> Subject: [opensocial-and-gadgets-spec] Re: Proposal:
>> >> >> > UserPrefs
>> >> >> > > for
>> >> >> > > > > > > REST
>> >> >> > > > > > >> API
>> >> >> > > >
>> >> >> > > > > > >> :-)
>> >> >> > > >
>> >> >> > > > > > >> I think I got some bad information. Sounds like
>> >> >> > > > > > >> userprefs
>> >> >> > are
>> >> >> > > still
>> >> >> > > > > > >> being used by a segment of gadgets. Does this api map
>> >> >> > > > > > >> into
>> >> >> > the
>> >> >> > > restful
>> >> >> > > > > > >> space when there is already a js api?
>> >> >> > > >
>> >> >> > > > > > >> Bob
>> >> >> > > >
>> >> >> > > > > > >> On Wed, Oct 15, 2008 at 4:12 PM, Zhen Wang
>> >> >> > <wa...@google.com>
>> >> >> > > wrote:
>> >> >> > > > > > >>> Userprefs can also be used to easily customize a
>> >> >> > > > > > >>> gadget
>> >> via
>> >> >> > > URL
>> >> >> > > > > > >> parameters.
>> >> >> > > >
>> >> >> > > > > > >>> On Wed, Oct 15, 2008 at 3:34 PM, Chris Chabot
>> >> >> > > <chab...@google.com>
>> >> >> > > > > > >> wrote:
>> >> >> > > >
>> >> >> > > > > > >>>> User preferences still have a place in a lot of apps
>> >> >> > > (iGoogle style
>> >> >> > > > > > >> ones
>> >> >> > > > > > >>>> anyhow!), so I think the chances of it going away any
>> >> time
>> >> >> > > soon is
>> >> >> > > > > > >> rather
>> >> >> > > > > > >>>> slim.
>> >> >> > > >
>> >> >> > > > > > >>>> Besides it's a lot simpler to do something like:
>> >> >> > > > > > >>>> <UserPref name="sign" datatype="enum"
>> >> >> > > default_value="MyChoice">
>> >> >> > > > > > >>>> <EnumValue value="1" display_value="first choice"/>
>> >> >> > > > > > >>>> <EnumValue value="2" display_value="second choice"/>
>> >> >> > > > > > >>>> </UserPref>
>> >> >> > > >
>> >> >> > > > > > >>>> Is a lot easier then coding your own UI for managing
>> >> >> > > preferences
>> >> >> > > > > > >> right?
>> >> >> > > > > > >>>> Also user prefs are always filled in by the sever (by
>> >> >> > > hangman
>> >> >> > > > > > >> substitution),
>> >> >> > > > > > >>>> so no round trips or preloading requests required
>> >> either..
>> >> >> > > >
>> >> >> > > > > > >>>> All in all I imagine it still has some value, and I
>> >> >> > > > > > >>>> can't
>> >> >> > > remember
>> >> >> > > > > > >> reading
>> >> >> > > > > > >>>> that they were depreciated, do you have a link to
>> >> >> > > > > > >>>> this
>> >> >> > > thread that
>> >> >> > > > > > >> you could
>> >> >> > > > > > >>>> share? (because I might be missing something obvious
>> >> here)
>> >> >> > > >
>> >> >> > > > > > >>>> -- Chris
>> >> >> > > >
>> >> >> > > > > > >>>> On Thu, Oct 16, 2008 at 12:13 AM, Bob Evans
>> >> >> > > <bobev...@google.com>
>> >> >> > > > > > >> wrote:
>> >> >> > > >
>> >> >> > > > > > >>>>> My understanding is that appdata store was the new
>> >> >> > > > > > >>>>> user
>> >> >> > > prefs and
>> >> >> > > > > > >> that
>> >> >> > > > > > >>>>> user prefs was deprecated. Seems like it should be
>> >> >> > removed
>> >> >> > > from the
>> >> >> > > > > > >>>>> spec for 0.9 since they provide essentially
>> >> >> > > > > > >>>>> duplicate
>> >> >> > > > > > > functionality.
>> >> >> > > >
>> >> >> > > > > > >>>>> On Thu, Oct 9, 2008 at 1:03 PM, Scott Seely
>> >> >> > > <sSe...@myspace.com>
>> >> >> > > > > > >> wrote:
>> >> >> > > > > > >>>>> > The REST API is missing support for
>> >> >> > > > > > >>>>> > UserPreferences.
>> >> >> > We'd
>> >> >> > > like to
>> >> >> > > > > > >> add
>> >> >> > > > > > >>>>> > the
>> >> >> > > > > > >>>>> > documentation to the RESTful API docs at
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > > >http://www.opensocial.org/Technical-Resources/opensocial-spec-
>> >> >> > > v081/restf
>> >> >> > > > > > >> ul-protocol.
>> >> >> > > >
>> >> >> > > > > > >>>>> > 2.6 User Preferences
>> >> >> > > >
>> >> >> > > > > > >>>>> > UserPreferences stores user preferences on behalf
>> >> >> > > > > > >>>>> > of
>> >> an
>> >> >> > > > > > >> application.
>> >> >> > > > > > >>>>> > The
>> >> >> > > > > > >>>>> > standard unit of UserPreferences is all of the
>> >> >> > preference
>> >> >> > > > > > >> information
>> >> >> > > > > > >>>>> > stored
>> >> >> > > > > > >>>>> > for a given application on behalf of a given user.
>> >> >> > > > > > >>>>> > The
>> >> >> > > API also
>> >> >> > > > > > >>>>> > supports
>> >> >> > > > > > >>>>> > other types of queries, described in section 6.5.
>> >> >> > > > > > >>>>> > To
>> >> >> > > retrieve a
>> >> >> > > > > > >> subset
>> >> >> > > > > > >>>>> > of
>> >> >> > > > > > >>>>> > fields, use the fields= selector syntax, described
>> >> >> > > > > > >>>>> > in
>> >> >> > > section
>> >> >> > > > > > > 6.6.
>> >> >> > > >
>> >> >> > > > > > >>>>> > An isolated Preferences example
>> >> >> > > >
>> >> >> > > > > > >>>>> > The first example is of a preference request
>> >> >> > > > > > >>>>> > returning
>> >> >> > > all
>> >> >> > > > > > >> preferences
>> >> >> > > > > > >>>>> > for
>> >> >> > > > > > >>>>> > an application and user:
>> >> >> > > >
>> >> >> > > > > > >>>>> > application/json representation:
>> >> >> > > >
>> >> >> > > > > > >>>>> > {
>> >> >> > > >
>> >> >> > > > > > >>>>> > "lang": "en",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "country": "US",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "moduleId": "24341",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "arrayValues": {
>> >> >> > > >
>> >> >> > > > > > >>>>> > "favoriteColors": [ "blue", "red"],
>> >> >> > > >
>> >> >> > > > > > >>>>> > "statusMessages": [ "online",
>> >> >> > > > > > >>>>> > "offline"]
>> >> >> > > >
>> >> >> > > > > > >>>>> > },
>> >> >> > > >
>> >> >> > > > > > >>>>> > "boolValues": {
>> >> >> > > >
>> >> >> > > > > > >>>>> > "boolVal1": "true",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "boolVal2": "false"
>> >> >> > > >
>> >> >> > > > > > >>>>> > },
>> >> >> > > >
>> >> >> > > > > > >>>>> > "intValues": {
>> >> >> > > >
>> >> >> > > > > > >>>>> > "millisecondsOnline": "1234567",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "highScore": "8600"
>> >> >> > > >
>> >> >> > > > > > >>>>> > },
>> >> >> > > >
>> >> >> > > > > > >>>>> > "floatValues": {
>> >> >> > > >
>> >> >> > > > > > >>>>> > "e": "2.71828",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "pi": "3.14159"
>> >> >> > > >
>> >> >> > > > > > >>>>> > },
>> >> >> > > >
>> >> >> > > > > > >>>>> > "stringValues": {
>> >> >> > > >
>> >> >> > > > > > >>>>> > "stringVal1": "hi",
>> >> >> > > >
>> >> >> > > > > > >>>>> > "stringVal2": "bye"
>> >> >> > > >
>> >> >> > > > > > >>>>> > }
>> >> >> > > >
>> >> >> > > > > > >>>>> > }
>> >> >> > > >
>> >> >> > > > > > >>>>> > application/xml representation:
>> >> >> > > >
>> >> >> > > > > > >>>>> > <userPreferences
>> >> >> > > > > > > xmlns="http://ns.opensocial.org/2008/opensocial">
>> >> >> > > >
>> >> >> > > > > > >>>>> > <lang>en</lang>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <country>US</country>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <moduleId>24341</moduleId>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <arrayValues>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <key>favoriteColors</key>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <value>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <entry>blue</entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <entry>red</entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > </value>
>> >> >> > > >
>> >> >> > > > > > >>>>> > </entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <key>statusMessages</key>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <value>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <entry>online</entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > <entry>offline</entry>
>> >> >> > > >
>> >> >> > > > > > >>>>> > </value>
>> >> >> > > >
>> >> >> > > > > > >>>>> >
>> >> >
>> >> > ...
>> >> >
>> >> > [Message clipped]
>> >>
>> >> >
>> >
>> >
>> >
>> > >
>> >
>>
>>
>
>
> >
>

[Eiji Kitamura]

Hi


It's been a while since I last posted to this list...:)

I just noticed Evan's proposal for visibility of AppData by reading
Brian's email.
I strongly agree with the idea of Evan's proposal.
Privacy is virtue of social web and something we should take into
account in OpenSocial.


Eiji,

(Please don't forget about Activity's privacy!!)
http://wiki.opensocial.org/index.php?title=Prop_004:_Activity_Recipient_Control

2009/2/20 Brian Eaton <bea...@google.com>: