You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Sean McCarthy <se...@clanmccarthy.net> on 2008/02/28 07:28:20 UTC
UserPref persistence
Hi all,
After a possibly not-so-thorough reading through of the gadget API,
the shindig source and the shindig-dev list archives I can't
determine if there's
1. A specification/API for the persistence of UserPrefs to a store
2. Any intent to create a persistent store other than the
CookieBasedUserPrefStore implementation already in shindig
So, I guess my question is can anyone enlighten on the above?
If there aren't any specific plans to create a non-cookie persistence
mechanism then I can happily attempt it myself, but if doing so I'd
like to make sure I was following a specification (i.e. some RESTful
service API?) if it existed.
--
Sean
Re: UserPref persistence
Posted by Kevin Brown <et...@google.com>.
On Thu, Feb 28, 2008 at 3:59 AM, Sean McCarthy <se...@clanmccarthy.net>
wrote:
>
> On 28/02/2008, at 5:51 PM, Kevin Brown wrote:
>
> > On Wed, Feb 27, 2008 at 10:28 PM, Sean McCarthy
> > <se...@clanmccarthy.net>
> > wrote:
> >
> >> Hi all,
> >>
> >> After a possibly not-so-thorough reading through of the gadget API,
> >> the shindig source and the shindig-dev list archives I can't
> >> determine if there's
> >>
> >> 1. A specification/API for the persistence of UserPrefs to a store
> >
> >
> > Up to the container. Every container has their own way of storing
> > data --
> > you register your own set_pref rpc handler and do whatever you like
> > beyond
> > that. Some sites might store this to a mysql server, others might
> > store it
> > in cookies.
>
> Cool, well that makes things flexible! I thought there might at least
> be an abstraction to the actual store (whatever form that actually
> takes) in the form of a standard API.
>
> So the set_pref rpc handler you're referring to is the one declared
> in gadgets,js?
>
> It looks like a matter of creating a subclass of UserPrefStore (like
> the CookieBasedUserPrefStore example) and then register it with a
> statement like:
>
> gadgets.Container.prototype.userPrefStore = new gadgets.MyPrefStore();
>
> Is this what you meant?
If you really want. I can't give a strong recommendation to using
gadgets.jsin a production site at this point in time, though. I'd
suggest just
sourcing the rpc code from the gadgets server (<host>/gadgets/js/rpc.js?c=1)
and registering your own handlers.
I'd also recommend using the rpc servlet to get gadget meta data rather than
relying on the hacky stuff that's going on now.
Eventually someone will probably rewrite gadgets.js to make it suitable for
use on real websites, but right now it's pretty primitive.
>
> Thanks
> --
> Sean
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
Re: UserPref persistence
Posted by "Jun Yang (杨骏)" <jy...@google.com>.
On Thu, Feb 28, 2008 at 3:59 AM, Sean McCarthy <se...@clanmccarthy.net>
wrote:
>
> On 28/02/2008, at 5:51 PM, Kevin Brown wrote:
>
> > On Wed, Feb 27, 2008 at 10:28 PM, Sean McCarthy
> > <se...@clanmccarthy.net>
> > wrote:
> >
> >> Hi all,
> >>
> >> After a possibly not-so-thorough reading through of the gadget API,
> >> the shindig source and the shindig-dev list archives I can't
> >> determine if there's
> >>
> >> 1. A specification/API for the persistence of UserPrefs to a store
> >
> >
> > Up to the container. Every container has their own way of storing
> > data --
> > you register your own set_pref rpc handler and do whatever you like
> > beyond
> > that. Some sites might store this to a mysql server, others might
> > store it
> > in cookies.
>
> Cool, well that makes things flexible! I thought there might at least
> be an abstraction to the actual store (whatever form that actually
> takes) in the form of a standard API.
>
> So the set_pref rpc handler you're referring to is the one declared
> in gadgets,js?
>
> It looks like a matter of creating a subclass of UserPrefStore (like
> the CookieBasedUserPrefStore example) and then register it with a
> statement like:
>
> gadgets.Container.prototype.userPrefStore = new gadgets.MyPrefStore();
>
Yes, this is exactly how it's designed to accommodate custom
implementations. Other components follow the same pattern.
> Is this what you meant?
>
> Thanks
> --
> Sean
>
Jun
Re: UserPref persistence
Posted by Sean McCarthy <se...@clanmccarthy.net>.
On 28/02/2008, at 5:51 PM, Kevin Brown wrote:
> On Wed, Feb 27, 2008 at 10:28 PM, Sean McCarthy
> <se...@clanmccarthy.net>
> wrote:
>
>> Hi all,
>>
>> After a possibly not-so-thorough reading through of the gadget API,
>> the shindig source and the shindig-dev list archives I can't
>> determine if there's
>>
>> 1. A specification/API for the persistence of UserPrefs to a store
>
>
> Up to the container. Every container has their own way of storing
> data --
> you register your own set_pref rpc handler and do whatever you like
> beyond
> that. Some sites might store this to a mysql server, others might
> store it
> in cookies.
Cool, well that makes things flexible! I thought there might at least
be an abstraction to the actual store (whatever form that actually
takes) in the form of a standard API.
So the set_pref rpc handler you're referring to is the one declared
in gadgets,js?
It looks like a matter of creating a subclass of UserPrefStore (like
the CookieBasedUserPrefStore example) and then register it with a
statement like:
gadgets.Container.prototype.userPrefStore = new gadgets.MyPrefStore();
Is this what you meant?
Thanks
--
Sean
Re: UserPref persistence
Posted by Kevin Brown <et...@google.com>.
On Wed, Feb 27, 2008 at 10:28 PM, Sean McCarthy <se...@clanmccarthy.net>
wrote:
> Hi all,
>
> After a possibly not-so-thorough reading through of the gadget API,
> the shindig source and the shindig-dev list archives I can't
> determine if there's
>
> 1. A specification/API for the persistence of UserPrefs to a store
Up to the container. Every container has their own way of storing data --
you register your own set_pref rpc handler and do whatever you like beyond
that. Some sites might store this to a mysql server, others might store it
in cookies.
2. Any intent to create a persistent store other than the
> CookieBasedUserPrefStore implementation already in shindig
If / when we have an appdata implementation, we'll probably wire that up,
but even then it'll just be a dummy file based mechanism. This is highly
dependent on your own site's infrastructure. There's no way for shindig to
be able to decide what's "right".
>
>
> So, I guess my question is can anyone enlighten on the above?
>
> If there aren't any specific plans to create a non-cookie persistence
> mechanism then I can happily attempt it myself, but if doing so I'd
> like to make sure I was following a specification (i.e. some RESTful
> service API?) if it existed.
The specification here is the set_pref handler of gadgets.rpc. Beyond that,
it's all in the hands of the container.