About App-Id when retrieving activities

73 views
Skip to first unread message

Laurent-Walter Goix

unread,
Jun 24, 2013, 5:25:46 AM6/24/13
to opensocial-an...@googlegroups.com
Hi all,

i am wondering the need for the "@app" / App-Id when retrieving activities, that currently prevents from retrieving activities issued by another app. 
This seems to be copied from the "old" activity service but i couldn't find other methods (post, put,delete) on that service nor on any other service
(except appdata) that would make use of this app-id in the uri-fragment. 

can anyone describe what is the concrete need for this and if so why is it only used 1) when requesting information about a specific activity and not for @all, @friends etc, and 2) when requesting activities and not people, groups etc.

could this be eventually removed from the path? alternatively would a "@all" be acceptable in that uri fragment to also support retrieving from *any* app?

any feedback would be appreciated possibly to clarify this in 2.5.1
thanks
walter

PS: please see issue 1320 for the original reference to this issue

Matthew Marum

unread,
Jun 24, 2013, 4:14:26 PM6/24/13
to opensocial-an...@googlegroups.com
FYI.. here's the new link to this issue in our Github repository.
(Unfortunately the numbering is a bit different)

So I believe Jive makes use of application activity streams which was why it was kept in the newer standard.  The App-Id segment wouldn't prevent you from retrieving activities from another app if you knew the App-Id.

Can anybody comment on how other containers (IBM, Rave) know how they've setup their activity stream service?  How are people using App-Ids?

Matt

Bill Looby

unread,
Jul 8, 2013, 8:50:19 AM7/8/13
to opensocial-an...@googlegroups.com
In IBM we have two uses for the AppId segment,

1. If you use a 'standard' application id, it operates as a filter on the stream (e.g. viewing only 'files' entries on my stream) and corresponds to the generator id provided for that application. These ids can also be registered so that they are presented as filter options in the UX.

2. We have 'special' application ids that do not correspond strictly to generator ids, so we prefix this with an @. Some example of these are : @communities - view anything from communities you are following, even if the generator is a wiki in that community. @profiles - view anything received as a result of following people.

Because it's essentially a filter, that should already be present in a posted Activity entry, there is little need for PUT and POST to look at the app id on the url (and the support of special app ids could make it confusing), and DELETE (where permitted) is always by Activity entry id.


Laurent-Walter Goix

unread,
Jul 10, 2013, 5:38:00 AM7/10/13
to opensocial-an...@googlegroups.com
thank you all for your feedbacks. afaik the app-id segment is needed and enough justified in GETs although some usages seem a bit confusing to me wrt group-Id segment.
at this point to solve the issue i would suggest to add an "@all" alias to the app-id segment definition (besides, @app and object-id that could cover the case where the app doesn't care, or better, do cares about retrieving all activities no matter the app that generated the activity.

if this works for all i could submit a patch to the app-id definition, make the oma spec updated consequently and then go for (quickly) releasing both OMA SNEW 1.0 and OS 2.5.1 asap (hopefully in time for the upcoming workshop)

please let me know
thanks
walter

Matthew Marum

unread,
Jul 10, 2013, 1:59:10 PM7/10/13
to opensocial-an...@googlegroups.com
+1 from me Walter.  Once you put together patch, I can create issue and apply it and we can get OS 2.5.1 closed out.

Matt


--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.
To post to this group, send email to opensocial-an...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opensocial-and-gadgets-spec/7e29881a-4e90-4b14-9faa-5a92f2c9e10d%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Laurent-Walter Goix

unread,
Jul 12, 2013, 9:03:35 AM7/12/13
to opensocial-an...@googlegroups.com
Thank you matt.

(trying to re-write my previous answer that ggroups made disappear...)

thinking more about the usage of the app-id segment:
1-when used as last segment in GET, the @all value is probably useless as implied, but surely a specific app-id or @app are meaningful.
2-the use before one or more activity-id(s) is the one that we're trying to solve based on the following use case:

let's suppose an app has got knowledge of some activity-id and wants to get details about it. but it doesn't know which app has generated it (no "generator" property etc), and may not care. so tentatively at the moment it can try with an @app, that indicates itself, which could be different from the one that originally generated the app.

the question is:
a) is it up to the server implementation to decide whether to ignore the app-id segment in that case to provide the info, or to forbid access if it does not match?
b) should indeed a new reserved value be added to state "don't know/don't care", and is "@all" the most appropriate keyword for that meaning (that would allow to be "transparent" if used as last segment)?

thanks for your feedback. at this point it may only impact either OS or OMA spec...

regards
walter


Il giorno mercoledì 10 luglio 2013 19:59:10 UTC+2, Matthew Marum ha scritto:
+1 from me Walter.  Once you put together patch, I can create issue and apply it and we can get OS 2.5.1 closed out.

Matt
On Wed, Jul 10, 2013 at 5:38 AM, Laurent-Walter Goix <laurentwa...@gmail.com> wrote:
thank you all for your feedbacks. afaik the app-id segment is needed and enough justified in GETs although some usages seem a bit confusing to me wrt group-Id segment.
at this point to solve the issue i would suggest to add an "@all" alias to the app-id segment definition (besides, @app and object-id that could cover the case where the app doesn't care, or better, do cares about retrieving all activities no matter the app that generated the activity.

if this works for all i could submit a patch to the app-id definition, make the oma spec updated consequently and then go for (quickly) releasing both OMA SNEW 1.0 and OS 2.5.1 asap (hopefully in time for the upcoming workshop)

please let me know
thanks
walter


Il giorno lunedì 8 luglio 2013 14:50:19 UTC+2, Bill Looby ha scritto:
In IBM we have two uses for the AppId segment,

1. If you use a 'standard' application id, it operates as a filter on the stream (e.g. viewing only 'files' entries on my stream) and corresponds to the generator id provided for that application. These ids can also be registered so that they are presented as filter options in the UX.

2. We have 'special' application ids that do not correspond strictly to generator ids, so we prefix this with an @. Some example of these are : @communities - view anything from communities you are following, even if the generator is a wiki in that community. @profiles - view anything received as a result of following people.

Because it's essentially a filter, that should already be present in a posted Activity entry, there is little need for PUT and POST to look at the app id on the url (and the support of special app ids could make it confusing), and DELETE (where permitted) is always by Activity entry id.


--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadgets-spec+unsub...@googlegroups.com.

To post to this group, send email to opensocial-an...@googlegroups.com.

Ryan Baxter

unread,
Jul 13, 2013, 10:06:54 AM7/13/13
to opensocial-an...@googlegroups.com


On Friday, July 12, 2013 9:03:35 AM UTC-4, Laurent-Walter Goix wrote:
Thank you matt.

(trying to re-write my previous answer that ggroups made disappear...)

thinking more about the usage of the app-id segment:
1-when used as last segment in GET, the @all value is probably useless as implied, but surely a specific app-id or @app are meaningful.
2-the use before one or more activity-id(s) is the one that we're trying to solve based on the following use case:

let's suppose an app has got knowledge of some activity-id and wants to get details about it. but it doesn't know which app has generated it (no "generator" property etc), and may not care. so tentatively at the moment it can try with an @app, that indicates itself, which could be different from the one that originally generated the app.

the question is:
a) is it up to the server implementation to decide whether to ignore the app-id segment in that case to provide the info, or to forbid access if it does not match?
I think it should just ignore it and return the activity specified by the id.  I think we should make note of the expected behavior in the spec.
b) should indeed a new reserved value be added to state "don't know/don't care", and is "@all" the most appropriate keyword for that meaning (that would allow to be "transparent" if used as last segment)?
I don't think we need a new value to represent this use case.

Have you tried these use cases against Shindig to see if we need to update the reference implementation as well?

Laurent-Walter Goix

unread,
Jul 17, 2013, 9:55:33 AM7/17/13
to opensocial-an...@googlegroups.com
Thank you Ryan,
 
some answers inline
 

Il giorno sabato 13 luglio 2013 16:06:54 UTC+2, Ryan Baxter ha scritto:


On Friday, July 12, 2013 9:03:35 AM UTC-4, Laurent-Walter Goix wrote:
Thank you matt.

(trying to re-write my previous answer that ggroups made disappear...)

thinking more about the usage of the app-id segment:
1-when used as last segment in GET, the @all value is probably useless as implied, but surely a specific app-id or @app are meaningful.
when looking more into details at the Social API Server spec it currently says: "If not included, the container MUST return ActivityEntries created by the currently authenticated app.", which is different from my previous assumption of "all/any". This goes therefore in favor of the @all value for this use case, unless we want to change the default behaviour (not sure of its impact on existing systems)
 
2-the use before one or more activity-id(s) is the one that we're trying to solve based on the following use case:

let's suppose an app has got knowledge of some activity-id and wants to get details about it. but it doesn't know which app has generated it (no "generator" property etc), and may not care. so tentatively at the moment it can try with an @app, that indicates itself, which could be different from the one that originally generated the app.

the question is:
a) is it up to the server implementation to decide whether to ignore the app-id segment in that case to provide the info, or to forbid access if it does not match?
I think it should just ignore it and return the activity specified by the id.  I think we should make note of the expected behavior in the spec.
 
based on the above, servers do not ignore it so we could easily define the expected behavior of the @all value
 
b) should indeed a new reserved value be added to state "don't know/don't care", and is "@all" the most appropriate keyword for that meaning (that would allow to be "transparent" if used as last segment)?
I don't think we need a new value to represent this use case.
 
Have you tried these use cases against Shindig to see if we need to update the reference implementation as well?
 
i have checked the php version of shindig i am using and ignores the parameter (may not be compliant, but anyway the php version is frozen afaik). the java version seems to consider it though (at least passes it correctly to the service class to handle it): the jsondbservice sample is quite permissive as it includes by default all activities that do not have their own in the activity object itself.
 
hence i would suggest to stick with the "@all" proposal that matt acknowledged previously and will submit a patch for it unless someone objects.
 
walter

Laurent-Walter Goix

unread,
Jul 22, 2013, 10:59:46 AM7/22/13
to opensocial-an...@googlegroups.com
I have submitted the patch(es) under issue 1320:
http://code.google.com/p/opensocial-resources/issues/detail?id=1320

walter

Matthew Marum

unread,
Jul 22, 2013, 9:40:45 PM7/22/13
to opensocial-an...@googlegroups.com
Thanks Walter.

I merged a pull request with your spec changes into the OpenSocial github repository.


Link to github commit

Matt



To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.

To post to this group, send email to opensocial-an...@googlegroups.com.

Laurent-Walter Goix

unread,
Jul 24, 2013, 6:24:06 AM7/24/13
to opensocial-an...@googlegroups.com
Thanks Matt,
 
i just noticed i made an error when linking the App-Id URL in the patch for Social-API-Server.xml#rfc.section.2.3.1.1, referencing Core-Data#App-Id instead of Social-Data#App-Id...
 
can you easily fix it or do you need me to submit a patch?
thanks
walter
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadgets-spec+unsubs...@googlegroups.com.

To post to this group, send email to opensocial-an...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadgets-spec+unsub...@googlegroups.com.
To post to this group, send email to opensocial-an...@googlegroups.com.

Matthew Marum

unread,
Jul 24, 2013, 8:11:23 AM7/24/13
to opensocial-an...@googlegroups.com

I'll fix it soon, no worries.

Matt

To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.

To post to this group, send email to opensocial-an...@googlegroups.com.

Matthew Marum

unread,
Jul 24, 2013, 3:54:36 PM7/24/13
to opensocial-an...@googlegroups.com
Updated now.
Reply all
Reply to author
Forward
0 new messages