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
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.--
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.
+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.
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)?
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?
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opensocial-and-gadgets-spec/6abdc5ee-34a3-4aa8-accf-e70b3cbeab72%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadgets-spec+unsubs...@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.
--
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/opensocial-and-gadgets-spec/4cabc914-b7ec-40a5-8b98-7efd8da4114f%40googlegroups.com.