Wonderful idea! Any idea when the changes will be committed? (Looks like the last change was 2 months ago: http://svn.eu.apache.org/viewvc/incubator/shindig/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/AppDataService.java )
Thanks, Chirag On Thu, Nov 13, 2008 at 11:57 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > 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 >>>> >>> >> >
