Should appData be per appId or per instance (appId:modId)?

[Gregg Horan <gr...@dealer.com>]

I'm trying to clarify if appData is supposed to be shared or distinct across multiple instances of the same gadget(appId) for a given user (per the opensocial standard). 

I have initially implemented appData and userPrefs as dinstinct per instance.  Now I'm reading this wiki example and questioning that approach:
http://wiki.opensocial.org/index.php?title=The_Persistence_API 
which describes an app that relies on exactly the opposite behavior... someone turns off a beep setting for a gadget in their own profile - then expects to reference that same setting when viewing the same gadget (app) when being viewed in another person's profile.  That won't fly in my implementation.  Conversely, if the person in that example puts two copies of that app on their profile, they have no way to configure them differently.  So who's right?

It's easy to go down one road or the other, but it would seem to be a core behavior that would be dictated by the spec.  Have I missed it?

Thanks
Gregg

Re: Should appData be per appId or per instance (appId:modId)?

[Mat Mannion <M....@warwick.ac.uk>]

The way we've implemented it in our system is to have appData indexed
by (user, appId) and for userPrefs to be per-instance. So the
behaviour you describe, where appData is shared between two copies of
the app on their profile, is exactly how we've done it.

I must admit, though, that I can't for the life of me remember WHY I
implemented it that way, or have any reference as to the reasoning.

Regards,

Mat

On 26 August 2010 05:13, Gregg Horan <gr...@dealer.com> wrote:
> I'm trying to clarify if appData is supposed to be shared or distinct across multiple instances of the same gadget(appId) for a given user (per the opensocial standard).
>
> I have initially implemented appData and userPrefs as dinstinct per instance.  Now I'm reading this wiki example and questioning that approach:
> http://wiki.opensocial.org/index.php?title=The_Persistence_API
> which describes an app that relies on exactly the opposite behavior... someone turns off a beep setting for a gadget in their own profile - then expects to reference that same setting when viewing the same gadget (app) when being viewed in another person's profile.  That won't fly in my implementation.  Conversely, if the person in that example puts two copies of that app on their profile, they have no way to configure them differently.  So who's right?
>
> It's easy to go down one road or the other, but it would seem to be a core behavior that would be dictated by the spec.  Have I missed it?
>
> Thanks
> Gregg



-- 
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL

Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk