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 >> >
