Update on this: AppDataService interface methods now take an enum Type parameter that specified the type of parameter being stored. Current types are APPDATA and OAUTH. USERPREFS could be added easily.
I need to change the AppDataService methods so they take a boolean option "ignoreModuleId", so that you can store values for all instances of a gadget (think two instances of the same gadget on a page.) The AppDataService interface is interesting in that it takes *both* a security token and an appid parameter: what if token.getAppId() is not equal to appId? Is this an artifact of the REST and JSON-RPC wire format not dealing explicitly with authentication issues, or is there a really good reason to have two different versions of the app id going into the same method? On Tue, Nov 11, 2008 at 8:37 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > OK. I think having *InternalPersonData methods gets us closer to > being able to store user prefs and other goodies in there. We'd have > a UserPrefHandler servlet that does appropriate ACL checks prior to > fetching the data. > > I'm not planning on writing that any time soon, but I'll keep it in > mind as I muck around in the app data code. > > On Mon, Nov 10, 2008 at 6:07 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: >> I like this idea. I'd also like to see an implementation of UserPrefs on app >> data as well, since that's the way most people are implementing it anyway. >> >> On Mon, Nov 10, 2008 at 11:17 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: >> >>> Hey folks - >>> >>> I'd like to make it easier for shindig deployments to use OAuth by >>> reusing the app data store for per-user and per-gadget persistent >>> storage. >>> >>> Proposal: >>> 1) Add three new methods to AppDataService, >>> getInternalPersonDataPrivate, updateInternalPersonData, and >>> deleteInternalPersonData. These would not be exposed to any servlets, >>> they would only be used by internal code. >>> >>> 2) Implement those methods in JsonDbOpenSocialService as filters on >>> top of filter names. Fields prefixed with __internal_ would only be >>> available via the *InternalPersonData methods, not via the other >>> PersonData methods. This will prevent javascript code from reading >>> OAuth data directly. >>> >>> 3) Create an implementation of OAuthStore built on top of >>> AppDataService. AppDataOAuthStore would >>> a) map the OAuth data on to the appdata schema. >>> b) handle encryption and decryption of keys to prevent them from >>> being accidentally disclosed. >>> >>> 4) Create a new shindig java subproject "integration" to house >>> AppDataOAuthStore and associate Guice modules. This is necessary to >>> avoid dependencies between social-api and gadgets. >>> >>> Comments? I'm working on a patch now. If this seems questionable to >>> anyone I'll stick the patch in Jira for review prior to submission. >>> If there are no objections I'll submit and then address any feedback. >>> >>> Cheers, >>> Brian >>> >> >
