You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Davies,Douglas" <da...@oclc.org> on 2011/06/27 15:58:49 UTC
Implementing userPrefs with common container
(I apologize if this posted to the dev group twice. My Entourage is
acting up again and this didn't seem to post the first time)
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
Re: Shindig support
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Hi Derek,
I think a lot of people would agree with your points below. I myself, and
may others I work with, have found it a little frustrating getting off the
ground with Shindig for many of the reasons you outline below. However we
need to start somewhere, if you are willing to document problems and the
corresponding solutions as you encounter them, you might want to consider
documenting them on the Shindig Wiki (
https://cwiki.apache.org/confluence/display/SHINDIG/Index%3bjsessionid=CA26246F597032FAAA9123CA01139E03
). I think the documentation for Shindig and OpenSocial started out
strong but has since become outdated as the spec and reference
implementation has progressed. As contributors to Shindig, we should all
be trying to improve the documentation as we continuously contribute to
the project.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 06/30/2011 03:47 PM
Subject: Re: Shindig support
Hi Derek,
These suggestions are very valuable. One way you can immediately help
to improve our docs and help system is to file JIRA
(https://issues.apache.org) issues for Apache Shindig project. This
could help us to keep track and plan what fixes or upgrades need to be
done.
The Shindig community is trying to make Shindig to be a turn-key
project with more pluggable customization points for easy deployment.
Really appreciate and looking forward for your help to make the
project better.
Hope this response helps to ease your concern a little bit.
- Henry
On Wed, Jun 29, 2011 at 10:19 PM, Derek Houghton <de...@chuwori.co.uk>
wrote:
> Dear Shindig Developers,
>
> As someone new to Shindig, but seeing it as a useful tool to plug into a
large scale bioinformatics project, I am finding it slow going enabling
the functionality I require.
> As brought to light in recent requests for help regarding OAuth,
UserPrefs and my own requirement for implementing a database back-end
there is not much to go on in the way of documentation.
> I was fortunate to get some help from Evgeny who pointed me in the right
direction for connecting my own back end database to Shindig. Without that
detailed help my project would have got seriously behind time. Even then I
had further issues with EclipseLink v Hibernate.
>
> My experience so far in contacting other users is that they have given
up on Shindig due to lack of support/ degree of difficulty or , ironically
for open source, having to pay someone else to resolve the issue.
> I am sure that this is not what you intend for your project.
>
> I have not given up on it yet but I am concerned that if I continue to
adapt Shindig for my own purposes then when I hand the project over in a
few months time, I am doing so without adequate reference/help material
from the apache team which my employers can fall back on.
>
> Is there a possibility that some of the development work goes into the
production of a help system in the form of tutorials or snippets of
example code being made available and maintained online? A little more
than 'You have to implement class X' would be invaluable.
>
> Under different circumstances I would like to be able to contribute to
the development of Shindig, but that is not in my remit at present. For
now I am just a user. I want to be able to use your product as much 'out
of the box' as possible. I would rather not have to spend a lot of time
figuring out exactly where I have to plug into Shindig in order to extend
or implement some apparently specific core functionality for version x/y.
> Even an upfront list of what does/doesn't work out of the box would be
time-saving.
>
> In the meantime here is a question for you: What do you think would be
the best way to save multiple states of the same gadget?
> ie A user views the same gadget at different times.
> On each occasion the user wishes to save a preferred state.
> The state that is saved involves the same parameters on each occasion -
but different values.
> The user would wish to recall these different states at any time.
> The user would want to share these different states with friends.
>
> My immediate thought is to employ a naming convention to distinguish
distinct states and writing the params to the app_data table (which is
person specific- yes?) and then modifying the relevant database classes
PersonDB etc.. to retrieve records based on the naming convention.
> Perhaps there is an alternative level I should be approaching this from?
>
> I appreciate all the work that is being done on Shindig by the
development team and hope that you view this as constructive feedback and
that the interest that exists in the Shindig project in the community
persists and gains momentum.
>
> Regards
> Derek
>
>
>
Re: Shindig support
Posted by Henry Saputra <he...@gmail.com>.
Hi Derek,
These suggestions are very valuable. One way you can immediately help
to improve our docs and help system is to file JIRA
(https://issues.apache.org) issues for Apache Shindig project. This
could help us to keep track and plan what fixes or upgrades need to be
done.
The Shindig community is trying to make Shindig to be a turn-key
project with more pluggable customization points for easy deployment.
Really appreciate and looking forward for your help to make the
project better.
Hope this response helps to ease your concern a little bit.
- Henry
On Wed, Jun 29, 2011 at 10:19 PM, Derek Houghton <de...@chuwori.co.uk> wrote:
> Dear Shindig Developers,
>
> As someone new to Shindig, but seeing it as a useful tool to plug into a large scale bioinformatics project, I am finding it slow going enabling the functionality I require.
> As brought to light in recent requests for help regarding OAuth, UserPrefs and my own requirement for implementing a database back-end there is not much to go on in the way of documentation.
> I was fortunate to get some help from Evgeny who pointed me in the right direction for connecting my own back end database to Shindig. Without that detailed help my project would have got seriously behind time. Even then I had further issues with EclipseLink v Hibernate.
>
> My experience so far in contacting other users is that they have given up on Shindig due to lack of support/ degree of difficulty or , ironically for open source, having to pay someone else to resolve the issue.
> I am sure that this is not what you intend for your project.
>
> I have not given up on it yet but I am concerned that if I continue to adapt Shindig for my own purposes then when I hand the project over in a few months time, I am doing so without adequate reference/help material from the apache team which my employers can fall back on.
>
> Is there a possibility that some of the development work goes into the production of a help system in the form of tutorials or snippets of example code being made available and maintained online? A little more than 'You have to implement class X' would be invaluable.
>
> Under different circumstances I would like to be able to contribute to the development of Shindig, but that is not in my remit at present. For now I am just a user. I want to be able to use your product as much 'out of the box' as possible. I would rather not have to spend a lot of time figuring out exactly where I have to plug into Shindig in order to extend or implement some apparently specific core functionality for version x/y.
> Even an upfront list of what does/doesn't work out of the box would be time-saving.
>
> In the meantime here is a question for you: What do you think would be the best way to save multiple states of the same gadget?
> ie A user views the same gadget at different times.
> On each occasion the user wishes to save a preferred state.
> The state that is saved involves the same parameters on each occasion - but different values.
> The user would wish to recall these different states at any time.
> The user would want to share these different states with friends.
>
> My immediate thought is to employ a naming convention to distinguish distinct states and writing the params to the app_data table (which is person specific- yes?) and then modifying the relevant database classes PersonDB etc.. to retrieve records based on the naming convention.
> Perhaps there is an alternative level I should be approaching this from?
>
> I appreciate all the work that is being done on Shindig by the development team and hope that you view this as constructive feedback and that the interest that exists in the Shindig project in the community persists and gains momentum.
>
> Regards
> Derek
>
>
>
Shindig support
Posted by Derek Houghton <de...@chuwori.co.uk>.
Dear Shindig Developers,
As someone new to Shindig, but seeing it as a useful tool to plug into a large scale bioinformatics project, I am finding it slow going enabling the functionality I require.
As brought to light in recent requests for help regarding OAuth, UserPrefs and my own requirement for implementing a database back-end there is not much to go on in the way of documentation.
I was fortunate to get some help from Evgeny who pointed me in the right direction for connecting my own back end database to Shindig. Without that detailed help my project would have got seriously behind time. Even then I had further issues with EclipseLink v Hibernate.
My experience so far in contacting other users is that they have given up on Shindig due to lack of support/ degree of difficulty or , ironically for open source, having to pay someone else to resolve the issue.
I am sure that this is not what you intend for your project.
I have not given up on it yet but I am concerned that if I continue to adapt Shindig for my own purposes then when I hand the project over in a few months time, I am doing so without adequate reference/help material from the apache team which my employers can fall back on.
Is there a possibility that some of the development work goes into the production of a help system in the form of tutorials or snippets of example code being made available and maintained online? A little more than 'You have to implement class X' would be invaluable.
Under different circumstances I would like to be able to contribute to the development of Shindig, but that is not in my remit at present. For now I am just a user. I want to be able to use your product as much 'out of the box' as possible. I would rather not have to spend a lot of time figuring out exactly where I have to plug into Shindig in order to extend or implement some apparently specific core functionality for version x/y.
Even an upfront list of what does/doesn't work out of the box would be time-saving.
In the meantime here is a question for you: What do you think would be the best way to save multiple states of the same gadget?
ie A user views the same gadget at different times.
On each occasion the user wishes to save a preferred state.
The state that is saved involves the same parameters on each occasion - but different values.
The user would wish to recall these different states at any time.
The user would want to share these different states with friends.
My immediate thought is to employ a naming convention to distinguish distinct states and writing the params to the app_data table (which is person specific- yes?) and then modifying the relevant database classes PersonDB etc.. to retrieve records based on the naming convention.
Perhaps there is an alternative level I should be approaching this from?
I appreciate all the work that is being done on Shindig by the development team and hope that you view this as constructive feedback and that the interest that exists in the Shindig project in the community persists and gains momentum.
Regards
Derek
Re: Implementing userPrefs with common container
Posted by Ryan J Baxter <rj...@us.ibm.com>.
It's not much but here is what I found.
http://docs.opensocial.org/display/OSD/UserPrefs+vs+AppData
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 07/06/2011 02:40 PM
Subject: Re: Implementing userPrefs with common container
Ryan,
Do you have link to the thread about this?
Been trying to search for it but couldnt find it.
- Henry
On Thu, Jun 30, 2011 at 6:06 PM, Ryan J Baxter <rj...@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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Henry Saputra <he...@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 <da...@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:craigmcc@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 <da...@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
>>>
>>>
>>
>>
>
>
>
>
Re: Implementing userPrefs with common container
Posted by Henry Saputra <he...@gmail.com>.
Ryan,
Do you have link to the thread about this?
Been trying to search for it but couldnt find it.
- Henry
On Thu, Jun 30, 2011 at 6:06 PM, Ryan J Baxter <rj...@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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Henry Saputra <he...@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 <da...@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:craigmcc@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 <da...@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
>>>
>>>
>>
>>
>
>
>
>
Re: Implementing userPrefs with common container
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Copying Mark to see if he can give us some details on when he plans on
implementing this.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Craig McClanahan <cr...@gmail.com>
To: dev@shindig.apache.org,
Date: 06/30/2011 10:59 PM
Subject: Re: Implementing userPrefs with common container
>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 <rj...@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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Henry Saputra <he...@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 <da...@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:craigmcc@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 <da...@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
> >>
> >>
> >
> >
>
>
>
>
Re: Implementing userPrefs with common container
Posted by Craig McClanahan <cr...@gmail.com>.
>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 <rj...@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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Henry Saputra <he...@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 <da...@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:craigmcc@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 <da...@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
> >>
> >>
> >
> >
>
>
>
>
Re: Implementing userPrefs with common container
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@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 <da...@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:craigmcc@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 <da...@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
>>
>>
>
>
Re: Implementing userPrefs with common container
Posted by Henry Saputra <he...@gmail.com>.
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 <da...@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:craigmcc@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 <da...@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
>>
>>
>
>
RE: Implementing userPrefs with common container
Posted by "Davies,Douglas" <da...@oclc.org>.
I got this working. I wasn't able to abstract it away as much as I
would have liked. I ended up creating a new class that extends
GadgetsHandlerService and overrides the inner MetadataGadgetContext
class which implements getUserPrefs. I then instruct Guice to use my
class instead of GadgetsHandlerService. My metadata request is now
returning my preferences I stored via the earlier set_pref
implementation. I think some work need to be done to
GadgetsHandlerService to really abstract this away and use the delegate.
I may tackle that at some point.
Thanks for the pointers.
doug
-----Original Message-----
From: Davies,Douglas
Sent: Wednesday, June 29, 2011 1:57 PM
To: dev@shindig.apache.org; 'craigmcc@gmail.com'
Subject: RE: Implementing userPrefs with common container
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:craigmcc@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 <da...@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
>
>
RE: Implementing userPrefs with common container
Posted by "Davies,Douglas" <da...@oclc.org>.
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:craigmcc@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 <da...@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
>
>
Re: Implementing userPrefs with common container
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, Jun 29, 2011 at 7:02 AM, Davies,Douglas <da...@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
>
>
RE: Implementing userPrefs with common container
Posted by "Davies,Douglas" <da...@oclc.org>.
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?
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