>From the OpenSocial Social Data Spec (version 1.1)[1]: "OpenSocial defines a data store that applications can use to read and write user-specific data. This data store can be read by anyone who can see the gadget, but only the VIEWER's data is writable."
This sentence is there in the 2.0 draft version as well[2], but there is some draft language in the Social API spec about allowing you, when you create or update appdata entries, to set the groupId of the group allowed to see the data[3] (defaults to "@app" for backwards compatibility, setting it to "@self" would mean only the viewer could read it). Don't know when/if that will make it in to the final version. Craig [1] http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#AppData [2] http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#AppData [3] http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-API-Server.xml#AppData-Service-Update On Thu, Jun 30, 2011 at 6:06 PM, Ryan J Baxter <rjbax...@us.ibm.com> wrote: > I am pretty sure your correct Henry. I know Mark was thinking about > redoing app data and preferences in the OpenSocial 2.0 spec, but I don't > think there was much progress on that. > > -Ryan > > Email: rjbax...@us.ibm.com > Phone: 978-899-3041 > developerWorks Profile > > > > From: Henry Saputra <henry.sapu...@gmail.com> > To: dev@shindig.apache.org, > Date: 06/29/2011 05:32 PM > Subject: Re: Implementing userPrefs with common container > > > > I think AppData is per person and per gagdet/app id. > So what Craig was saying that the same gadget could be run by > different user and it could ask for the user preference for other > user(s). > > - Henry > > On Wed, Jun 29, 2011 at 10:56 AM, Davies,Douglas <davi...@oclc.org> wrote: > > Craig, > > > > Thanks for the info. I thought appdata was per person, not per gadget. > > I'm probably misunderstanding something here. I will investigate. > > > > I'm also trying to find the correct server-side metadata plugin point. > > It looks like the MetadataGadgetContext class might be the right plugin > > point by implementing getUserPrefs(). But I don't see an easy way to do > > this since MetadataGadgetContext is a protected class in > > GadgetsHandlerService and there doesn't seem to be any Guice > > configuration around this module that I can inject something different. > > We build from the maven artifacts, so I don't really want to be > > *patching* any code here. > > > > Thanks, > > doug > > > > -----Original Message----- > > From: Craig McClanahan [mailto:craig...@gmail.com] > > Sent: Wednesday, June 29, 2011 1:26 PM > > To: dev@shindig.apache.org > > Subject: Re: Implementing userPrefs with common container > > > > On Wed, Jun 29, 2011 at 7:02 AM, Davies,Douglas <davi...@oclc.org> > > wrote: > > > >> I've implemented the set_pref rpc call and it's getting called > >> appropriately from the gadgets. I've got this sitting ontop of > > appdata > >> and it seems to be persisting my values fine. I am using the gadget > > url > >> combined with the preference name to generate the appdata store key. > > I > >> had to search/replace all non appdata friendly key characters > >> (AppHandler only allows alpha-numeric, dash, underscore, and period). > >> Does this sound like the right way to be doing this if I want to > >> leverage off of appdata? > >> > >> One caution on using appdata for this purpose -- all users of the same > > gadget can read the appdata settings for all users, and therefore could > > see > > other users's preference settings in your approach. That is not a good > > idea > > from a privacy perspective. > > > > In our implementation (Jive Software), we created additional RPC calls > > back > > to the server and stored the privacy settings in a database table keyed > > by > > user, gadget, and preference name. We go beyond the spec requirements > > and > > allow a gadget to define a custom view for their preferences, or default > > to > > constructing a generic one based on the data types. > > > > Craig McClanahan > > > >> > >> > >> I am now figuring out where to plugin to retrieve and override the > >> userprefs returned from the metadata/iframe calls. Again... any > >> feedback from anyone who has been through this process is appreciated. > >> > >> > >> > >> doug > >> > >> > >> > >> From: Davies,Douglas > >> Sent: Monday, June 27, 2011 9:59 AM > >> To: 'dev@shindig.apache.org' > >> Subject: Implementing userPrefs with common container > >> > >> > >> > >> I'm looking into implementing userPrefs with the common container, but > >> I'm unclear as to what is implemented and what just needs to be > >> extended. > >> > >> > >> > >> My first step is to implement set_pref and register it with rpc. I'm > >> thinking of implementing this using the appData api (as I've seen > > other > >> threads along those lines). I realize appData needs to be extended to > >> use a persistent store. I'm not sure what the default implementation > > is > >> using (in memory?). > >> > >> > >> > >> I would then think I need to modify the server side to return these > >> userPrefs (overriding the ones from the gadget spec). I'm not sure > >> where to plug into here to use my persistent store. It seems like the > >> old container way was for DefaultIframeUriManager to return this when > > it > >> created the iframe url. But I'm not sure that is what common > > container > >> is doing. I think I need to plug into the gadgets.metadata request. > >> > >> > >> > >> Also it appears that sites like iGoogle provide a user interface from > >> within the container to set the user prefs. Is it the containers or > > the > >> gadgets responsibility to do this or a little bit of both? I can see > > a > >> horoscope gadget using userPrefs to store a birthdate but not > >> necessarily have to have a separate settings panel like iGoogle > >> provides. > >> > >> > >> > >> Has anyone been through this process that would be willing to share > > what > >> they did? Is this something that the common container will eventually > >> support out of the box? How far off base am I with my thinking here? > >> > >> > >> > >> Thanks, > >> > >> Doug > >> > >> > > > > > > > >
