appId

[Lane LiaBraaten]

Does anyone have a use case where appId != "@app"?

appId is most relevant to Activites and AppData service..

Activities - appId is used to get activities created by a given app.  Seems like the valid use cases are

  1) Give me all the user's activities (GET activites/User-Id/)

  2) Give me all the users activities that my app created (GET activities/User-Id/@app)

Getting activities created by some other app seems strange...How did I get the other app's Id in the first place?

AppData - appId is used to get appData created by a given app.  Seems like we'd always want to restrict appData to only what was craeted by the app requesting it.  (Looks like this may be a copy/paste error, since the description for appId in the AppData section [1] says "appId : The app id to select *activities* for, or @app to indicate the currently requesting application."

Thanks,

Lane

[1] http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.7.4

[Jon]

Perhaps some container implementers who have implemented appId could
chime in.

AppId appears to be referenced in the authentication section of REST
and RPC. Thus @appId would refer to the appId in the authentication
context. Which brings up the questions:

1) How does the caller of REST/RPC get the appId?
2) Would containers ever support authentication w/o an appId?
3) Does appId fit the limited syntax of Object-Id, or is it a URL?
4) Who out there is using this part of the specification?

I'm fairly sure one answer to #4 is the gadget JavaScript, but that's
an internal contract, so those use cases are less interesting.

[Evan Gilbert]

There are a couple of strong use cases for @appId:

- 1st party gadgets / APIs - if you want to create an Activity viewer gadget for your site (as an example)

- Multiple gadgets from the same "app". We don't yet have a way for developers to link all their gadgets. Activity streams are a good glue between them

Having said this, the current spec is too vague and can't really support any standardization across containers, for the reasons Jon mentioned. Also, we need a wildcard (get all activities for a user).

I think it might make sense to remove it from the spec and ask any current implementers to propose an extension with all of the details filled in.

Evan

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.