In our implementation the siteid SHOULD be unique and specific to an instance of a gadget (I¹m still working out the details on this). So they won¹t be reused. That still means appdata could be queried and user preferences visible to others. However I¹m working off this comment...
> http://permalink.gmane.org/gmane.comp.web.shindig.devel/6998 > 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. Which I think says, eventually opensocial 2.0 containers SHOULD restrict visibility of appdata based on the groupid used when setting the appdata. Am I off base here? This means in the interim we have this gaping hole, so the gadgets we are developing (which are really our main focus for the container, not other gadgets) need to make sure no sensitive information is stored in user preferences. I figured I¹d move towards the spec instead of doing something completely different and having to catch up with the spec. But then again maybe I¹m trying to overload appdata too much, but the concepts seem so similar that I think the spec change would help converge them. So... With that said... Is an appdata implmentation of userprefs still something that would be useful in the default shindig implementation if that¹s the direction things are headed? Or does this lead one down the wrong path and maybe a cookie base implementation (like sample container used) is a better solution. doug On 7/28/11 8:41 PM, "Ryan J Baxter" <rjbax...@us.ibm.com> wrote: > Doug can you explain more about how your using appdata + site id to store > user prefs? I tried looking below but couldn't find an explanation. I > realize that every gadget site has a unique gadget id, but couldn't a > container choose to reuse a gadget site? Say a container renders gadget 1 > in site 1. Gadget 1 saves some user preferences using your > implementation. Then the container reuses site 1 to render gadget 2. In > theory couldn't gadget 2 now have access to gadget 1's preferences? > > -Ryan > > Email: rjbax...@us.ibm.com > Phone: 978-899-3041 > developerWorks Profile > > > > From: daviesd <davi...@oclc.org> > To: <dev@shindig.apache.org>, > Date: 07/28/2011 11:55 AM > Subject: Re: Example implementation for user prefs? > > > > Jesse, > > I think you are correct that it should be per instance. That's where the > siteid would come into play. At least that's how I'm reading it (and now > implementing it). In our case a particular gadget always renders in the > same > siteid. Two instances of the same gadget would have different siteids, > thus > different preferences. > > doug > > On 7/28/11 11:51 AM, "Ciancetta, Jesse E." <jc...@mitre.org> wrote: > >>> >> If you wish to persist preferences for a particular occurrence of a >>> >> gadget(per gadget url instance), then you'll need to keep track of the >>> >> site (the auto generated ids are less helpful), if you wish to provide >>> >> "per gadget url" preferences you can just ignore they siteid and return > or >>> >> persist the preferences for all gadgets coming from that url. >> > >> > But if we're talking about providing a reference implementation to > server as a >> > sample for anyone using the common container -- that implementation > should be >> > saving preferences per gadget instance, right? I believe that user >> > preferences are supposed to be stored per user/per gadget instance > (although I >> > just took a quick glance through the 2.0 spec and couldn't find any > language >> > to support that). >> > >> > Can anyone confirm or deny that to actually be the case (and maybe > provide a >> > reference to where it's specified)? >> > >>> >> From: daviesd <davi...@oclc.org> >>> >> To: <dev@shindig.apache.org>, >>> >> Date: 07/27/2011 03:22 PM >>> >> Subject: Re: Example implementation for user prefs? >>> >> >>> >> >>> >> >>> >> Dan, >>> >> >>> >> Nice! I'm still using 3.0.0-beta2, so hadn't seen this yet. Was there > an >>> >> earlier thread on how to use this? Can you explain how I hook into > this >>> >> and >>> >> provide a server-side implementation? And does this mean when I call >>> >> navigateGadget that I should now be providing a unique id for the > siteId >>> >> (maybe correlating to my spaceid?)? >>> >> >>> >> Thanks, >>> >> doug >>> >> >>> >> >>> >> On 7/27/11 1:50 PM, "Dan Dumont" <ddum...@us.ibm.com> wrote: >>> >> >>>> >>> FYI, there have been some recent changes in the common container to >>> >> expose >>>> >>> a callback to the container page that allows for the persisting and >>>> >>> retrieval of persisted preferences. >>>> >>> >>>> >>> /** >>>> >>> * @see setprefs.js setprefs feature. >>>> >>> */ >>>> >>> this.rpcRegister('set_pref', function(rpcArgs, key, value) { >>>> >>> var site = rpcArgs[osapi.container.GadgetSite.RPC_ARG_KEY]; >>>> >>> var setPrefs = >>>> >>> self.config_[osapi.container.ContainerConfig.SET_PREFERENCES]; >>>> >>> if (site && setPrefs) { // Check if site is not already closed. >>>> >>> var data = {}; >>>> >>> for (var i = 2, j = arguments.length; i < j; i += 2) { >>>> >>> data[arguments[i]] = arguments[i + 1]; >>>> >>> } >>>> >>> setPrefs(site.getId(), site.getActiveGadgetHolder().getUrl(), >>> >> data); >>>> >>> } >>>> >>> }); >>>> >>> >>>> >>> A container may specify functions to the CommonContainer that will be >>>> >>> called to retrieve and set preferences for a particular gadget. >>>> >>> Please also note that gadget site id will now prefer the id attribute > of >>>> >>> the gadget site element, so that named locations for specific gadgets >>> >> can >>>> >>> have preferences persisted accordingly. >>>> >>> >>>> >>> If you are going to be providing a default preference persistence > impl, >>> >> it >>>> >>> would be great if you could hook into this :) >>>> >>> >>>> >>> >>>> >>> >>>> >>> From: daviesd <davi...@oclc.org> >>>> >>> To: <dev@shindig.apache.org>, >>>> >>> Date: 07/27/2011 01:09 PM >>>> >>> Subject: Re: Example implementation for user prefs? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Paul, >>>> >>> >>>> >>> Sure. Give me a few days, I just got back from vacation. I'll have to >>>> >>> figure >>>> >>> out whether the container token will be sufficient for this, as I had > to >>>> >>> apply other patches to get the gadget token to be used. >>>> >>> >>>> >>> Thanks, >>>> >>> doug >>>> >>> >>>> >>> >>>> >>> On 7/27/11 12:58 PM, "Paul Lindner" <lind...@inuus.com> wrote: >>>> >>> >>>>> >>>> Can you write this up a patch so we can make this the default >>>>> >>>> implementation? This is something I've been meaning to do for > months. >>>>> >>>> >>>>> >>>> On Wed, Jul 27, 2011 at 8:58 AM, daviesd <davi...@oclc.org> wrote: >>>>> >>>> >>>>>> >>>>> Actually, I was lazy and went with the approach of layering > userprefs >>>> >>> on >>>>>> >>>>> top >>>>>> >>>>> of appdata as follows: >>>>>> >>>>> >>>>>> >>>>> container.rpcRegister('set_pref', function(rpcArgs, data) { >>>>>> >>>>> >>>>>> >>>>> var prefName = rpcArgs['a'][1]; >>>>>> >>>>> var prefKey = 'up_' + prefName; >>>>>> >>>>> var prefValue = rpcArgs['a'][2]; >>>>>> >>>>> >>>>>> >>>>> var data = {}; >>>>>> >>>>> data[prefKey] = prefValue; >>>>>> >>>>> >>>>>> >>>>> osapi.appdata.update({ >>>>>> >>>>> userid : '@me', >>>>>> >>>>> groupid : '@self', >>>>>> >>>>> appId : '@app', >>>>>> >>>>> data : data >>>>>> >>>>> >>>>>> >>>>> }).execute(function(response) { >>>>>> >>>>> }); >>>>>> >>>>> }); >>>>>> >>>>> >>>>>> >>>>> This is with anticipation that appdata and userprefs will align as >>>>>> >>>>> discussed >>>>>> >>>>> here: >>>>>> >>>>> >>>>>> >>>>> http://code.google.com/p/opensocial-resources/issues/detail?id=1182 >>>>>> >>>>> >>>>>> >>>>> Of course this also requires you to implement appdata server side. >>>> >>> Right >>>>>> >>>>> now I¹m just using the JsonDb implementation (in-memory), but we¹ll > be >>>>>> >>>>> writing a persistent layer soon. >>>>>> >>>>> >>>>>> >>>>> I also ran into issues with the correct token (the gadget one with > the >>>>>> >>>>> appid >>>>>> >>>>> that you¹ll need to use to index the data) being passed to the > appdata >>>>>> >>>>> request. You can search for my other thread about this. >>>>>> >>>>> >>>>>> >>>>> doug >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On 7/25/11 6:53 PM, "Henry Saputra" <henry.sapu...@gmail.com> >>> >> wrote: >>>>>> >>>>> >>>>>>> >>>>>> If you want the user pref to be persisted in the database you need > to >>>>>>> >>>>>> implement the server handler for it. >>>>>>> >>>>>> >>>>>>> >>>>>> I remember Doug Davies has tried to add persistent layer for user >>>>>>> >>>>>> pref. Maybe he could share his progress. >>>>>>> >>>>>> >>>>>>> >>>>>> Including him in the email. >>>>>>> >>>>>> >>>>>>> >>>>>> - Henry >>>>>>> >>>>>> >>>>>>> >>>>>> On Mon, Jul 25, 2011 at 3:42 PM, Mat Schaffer <m...@schaffer.me> >>> >> wrote: >>>>>>>>> >>>>>>>> So with some research it looks like I'm supposed to be > implementing >>>> >>> my >>>>>> >>>>> own >>>>>>>>> >>>>>>>> server module. Is that pretty much accurate? >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Again, any advice or RTFMs (with a link to the respective FMs) is >>>>>>>>> >>>>>>>> appreciated. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Thanks, >>>>>>>>> >>>>>>>> Mat >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> On Fri, Jul 22, 2011 at 10:20 AM, Mat Schaffer >>>>>>>>> <m...@schaffer.me> >>>>>> >>>>> wrote: >>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>>> So I noticed that UserPref items don't work on the sample >>>> >>> container >>>>>> >>>>> which >>>>>>>>>>> >>>>>>>>>> makes sense after finding this thread: >>>>>>>>>>> >>>>>>>>>> http://markmail.org/message/tlwtlo4mrnrpz4w5 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Is there any good example of best-practice for >>>>>>>>>>> implementing > user >>>>>> >>>>> prefs in >>>>>>>>>>> >>>>>>>>>> my containing application? Do I just make my own >>>>>> >>>>> shindig-container.js and >>>>>>>>>>> >>>>>>>>>> handleOpenUserPrefsDialog? And does the page we point to just >>>> >>> render >>>>>>>>>>> >>>>>>>>>> information into a div with id of `this.id`? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> The gmodule code appears to be obfuscated, so it's a bit hard > to >>>>>> >>>>> tell >>> >>>>>> >>>>> what >>>>>>>>>>> >>>>>>>>>> the right course of action would be. Any documentation or >>>> >>> assistance >>>>>>>>> >>>>>>>> would >>>>>>>>>>> >>>>>>>>>> be appreciated. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>> Mat >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >> >>> >> >>> >> >>> >> >> > >> > > > > > > >
