[0.8.1] Adding appId to the path of the activities urls

[Cassie]

In the rest apis the appdata urls include an appId but the activity urls do not. I think we should add the appId to the activity urls to make them match (and to give containers all the information they need to actually implement the endpoint).

I propose that we change the activity urls to look like this:

/activities/{guid}/@self/{appid}            -- Collection of activities generated by given user
/activities/{guid}/@friends/{appid}       -- Collection of activities for friends of the given user {guid}
/activities/{guid}/{groupid}/{appid}      -- Collection of activities for people in group {groupid} belonging to given user {uid}
/activities/{guid}/@self/{appid}/{activityid}   -- Individual activity resource; usually discovered from collection


(I just added /{appid} to the end of the first three and in the middle of the last one)

- Cassie

[Paul Walker]

Why wouldn’t the consumer key identify the app in both cases?

[John Panzer]

How would one query for the set of all activities generated by a given user, regardless of app id?  (Most apps may not have access to such data, but the container certainly does, and users certainly should be able to conceptually authorize such access to any app they choose.)

Beyond that, it's okay, though as Paul mentions the security context could take care of this easily and you need to check its app id to do filtering anyway.  (The last URL is a little strange in that the activity ID can easily encode the app ID if necessary, and you can't construct the URL in question without a priori knowledge of the activity ID anyway.)

John Panzer (http://abstractioneer.org)

[Louis Ryan]

I assume Cassie you meant....

/activities/{guid}/@self/{appid}            -- Collection of activities generated by an app for a given user
/activities/{guid}/@self                        -- Collection of activities generated by a given user
/activities/{guid}/@friends/{appid}       -- Collection of activities generated by an app for friends of the given user {guid}
/activities/{guid}/@friends                   -- Collection of activities generated by friends of the given user {guid}
etc...

this seems reasonable though we could use a an appId filtering query param instead.

[Cassie]

Yes - Louis' clarification of my proposal shows how you can query for
activities regardless of which app created it. This exactly mirrors
app data.

Paul - We don't get the appId from the auth context so that containers
can support more complex permissions. Say iLike wants to grab all the
activities for their top friends app, and in a separate call they want
to fetch all the activities for their super poke gadget. They should
be able to fetch both independently and shouldn't be tied by the auth
context.

Eventually I could even see some containers not checking the currently
authed app. You could just request activities from any app you like
and all requests would be approved. This could happen if, for example,
friend feed wanted to expose its data with the activities apis.

We could make this a query param, but if we do we should also make the
appdata urls include the appId as a query param instead of in the url.
They should be as symmetric as possible to reduce confusion for users
and implementors.

- Cassie

[Cassie]

Anybody else want to respond on this? I hope I clearly explained why
this is needed (ie its just like appdata) and with the special @app
token it shouldn't be harmful to any developers.

Louis and I seem to be the only +1s so we need 3 more.
Anybody wanna comment?

Thanks!
- Cassie

[Cassie]

To be very concrete - this would be the spec change:

XRDS Type: http://ns.opensocial.org/activities/0.8

guid : Container-globally-unique user identifier; owner or recipient of the activity data, or @me to indicate the requestor should be used

selector : One of

• A user-defined local group name to select activities from people in the group (a collection)
• @self to select the activities for user guid (a collection)
• @all to select all the universal set of contacts (a collection)
• @friends to select the activities from friends only (a collection)

appId : The app id to select activities for, or @app to indicate the currently requesting application.

Activity URI examples:

/activities/{guid}/@self                -- Collection of activities generated by given user

/activities/{guid}/@self/{appid}        -- Collection of activities generated by an app for a given user

/activities/{guid}/@friends             -- Collection of activities for friends of the given user {guid}

/activities/{guid}/@friends/{appid}     -- Collection of activities generated by an app for friends of the given user {guid}

/activities/{guid}/{groupid}            -- Collection of activities for people in group {groupid} belonging to given user {uid}
/activities/{guid}/{groupid}/{appid}    -- Collection of activities generated by an app for people in group {groupid} belonging to given user {uid}

/activities/{guid}/@self/{appid}/{activityid}   -- Individual activity resource; usually discovered from collection

/activities/@supportedFields            -- Returns all of the fields that the container supports on activity objects as an array in json and a repeated list in atom.

- Cassie

[Robert Evans]

+1

On Mon, Jul 28, 2008 at 6:57 PM, Cassie <do...@google.com> wrote:

[Evan Gilbert]

+1

[Zhen Wang]

+1

On Mon, Jul 28, 2008 at 6:57 PM, Cassie <do...@google.com> wrote:

[Scott Seely]

We have an issue with the URL of the form:

/activities/{guid}/@self/{appid}/{activityid}  

 

We have a notion of a activity stream for a given date. On a given date, we have the N most recent activities. The N+1^th activity causes the oldest activity to be pushed out of the stream. As such, an activityid does not have much meaning in our systems. The number of events is not fixed but is set depending on how many activities we can handle and still scale.

 

Within the documentation, there is a notion of an activity ID within the stream at http://code.google.com/apis/opensocial/docs/gdata/activities/developers_guide_protocol.html#Activities. The activity with ID a1 is always the newest activity. a2 would be the next youngest, and so on until we hit the limit. Between GETs, a particular ID may point to different activity content.

 

As a result, MySpace will probably not support this last URI. The URI does not make sense in our model. Activities are more like logging streams where they store some event in time.

[Scott Seely]

We have an issue with the URL of the form:

/activities/{guid}/@self/{appid}/{activityid}  

 

We have a notion of a activity stream for a given date. On a given date, we have the N most recent activities. The N+1^th activity causes the oldest activity to be pushed out of the stream. As such, an activityid does not have much meaning in our systems. The number of events is not fixed but is set depending on how many activities we can handle and still scale.

 

Within the documentation, there is a notion of an activity ID within the stream at http://code.google.com/apis/opensocial/docs/gdata/activities/developers_guide_protocol.html#Activities. The activity with ID a1 is always the newest activity. a2 would be the next youngest, and so on until we hit the limit. Between GETs, a particular ID may point to different activity content.

 

As a result, MySpace will probably not support this last URI. The URI does not make sense in our model. Activities are more like logging streams where they store some event in time. We will need to make this last URI a MAY instead of a MUST in the spec.

 

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Evan Gilbert
Sent: Tuesday, August 19, 2008 1:24 PM
To: opensocial-an...@googlegroups.com
Subject: Re: [0.8.1] Adding appId to the path of the activities urls

 

+1

[Cassie]

Just so you know - none of the urls are really MUSTs... the spec states that you can use any format for urls you like and support them any which way as long as it is in the xrds. I think this is a little too vague, but that is what we have at the moment.

So, in reality, this spec proposal doesn't actually affect any implementations although it would be great for all implementors to agree on a url schema...

Anyway, myspace not supporting the last url is spec wise aok.

- Cassie

[John Panzer]

Scott -- This means that your URLs for individual activities don't even approximate permalinks and can't be used for things like editing or cross-referencing (because the thing they point at has moved down along the stream).  How do you plan to allow such operations?

(I'm not sure what use such URLs would be really -- if you want the last 5 activities you can just grab the feed of activities and you don't care what their individual URLs are; I'm trying to figure out the use case for "give me whatever happens to be the 5th activity in an activity stream" alone.)

John Panzer (http://abstractioneer.org)

On Tue, Aug 19, 2008 at 2:39 PM, Scott Seely <SSe...@myspace.com> wrote:

[Marco Ensing]

What is the exact use case for one particular event? Our rolling event
log file is not to be used as the Application Data storage. Or
Application User Data storage.

Our main use case is that the application developer can show the
activity feed of its application on its own canvas. They don’t have to
host the data and/or implement this themselves.

Our smallest granularity of the event is per user\per day\per
application\per template

This last categorization is something we have not really discussed.
Every template, is its own category. So the ‘’RateMovie” template and
the “BuyMovie” template, do not share the daily aggregation per sender
of the event. But will become two individual events

Marco rated the movie “movie1,” “movie2” and “movie3”
“movie3” got 4 stars.

Marco bought the movie “movie2” and “movie5”
Click “here” to comment on his purchase.

ME

On Aug 19, 3:47 pm, "John Panzer" <jpan...@google.com> wrote:
> Scott -- This means that your URLs for individual activities don't even
> approximate permalinks and can't be used for things like editing or
> cross-referencing (because the thing they point at has moved down along the
> stream).  How do you plan to allow such operations?
>
> (I'm not sure what use such URLs would be really -- if you want the last 5
> activities you can just grab the feed of activities and you don't care what
> their individual URLs are; I'm trying to figure out the use case for "give
> me whatever happens to be the 5th activity in an activity stream" alone.)
>
> John Panzer (http://abstractioneer.org)
>
> On Tue, Aug 19, 2008 at 2:39 PM, Scott Seely <SSe...@myspace.com> wrote:
> >  We have an issue with the URL of the form:
>
> > /activities/{guid}/@self/{appid}/{activityid}
>
> > We have a notion of a activity stream for a given date. On a given date, we
> > have the N most recent activities. The N+1th activity causes the oldest
> > activity to be pushed out of the stream. As such, an activityid does not
> > have much meaning in our systems. The number of events is not fixed but is
> > set depending on how many activities we can handle and still scale.
>

> > * *

>
> > Within the documentation, there is a notion of an activity ID within the
> > stream at

> >http://code.google.com/apis/opensocial/docs/gdata/activities/develope....

> > The activity with ID a1 is always the newest activity. a2 would be the next
> > youngest, and so on until we hit the limit. Between GETs, a particular ID
> > may point to different activity content.
>
> > As a result, MySpace will probably not support this last URI. The URI does
> > not make sense in our model. Activities are more like logging streams where
> > they store some event in time. We will need to make this last URI a MAY
> > instead of a MUST in the spec.
>

> > *From:* opensocial-an...@googlegroups.com [mailto:
> > opensocial-an...@googlegroups.com] *On Behalf Of *Evan Gilbert
> > *Sent:* Tuesday, August 19, 2008 1:24 PM
> > *To:* opensocial-an...@googlegroups.com
> > *Subject:* Re: [0.8.1] Adding appId to the path of the activities urls
>
> > +1
>
> > On Tue, Aug 19, 2008 at 11:43 AM, Robert Evans <bobev...@google.com>
> > wrote:
>
> > +1

[John Panzer]

Right.  So you don't have individual URLs for individual activities, you just need a feed of the last N.  Don't provide individual URLs at all.  (This means that your users can't ever edit or delete an activity once posted, but I assume you're fine with that.)

If you do provide individual URLs, they SHOULD (RFC-speak) point at actual instances of activities, not at slots where activities might pass through.  But it sounds like you don't need to do this.

John Panzer (http://abstractioneer.org)

On Tue, Aug 19, 2008 at 4:10 PM, Marco Ensing <men...@myspace.com> wrote:

John,

 

What is the use case for one particular event? Our rolling event log file is not to be used as the Application Data storage. Or Application User Data storage.

 

Our main use case is that the application developer can show the activity feed of its application on its own canvas. They don't have to host the data and/or implement this themselves.

Our smallest granularity of the event is per user\per day\per application\per template

 

This last categorization is something we have not really discussed. Every template, is its own category. So the ''RateMovie" template and the "BuyMovie" template, do not share the daily aggregation per sender of the event. But will become two individual events

 

  Marco rated the movie "movie1," "movie2" and "movie3"

  "movie3" got 4 stars.

 

  Marco bought the movie "movie2" and "movie5"

  Click "here" to comment on his purchase.

 

 

 

ME

 

From: John Panzer [mailto:jpa...@google.com]
Sent: Tuesday, August 19, 2008 3:48 PM

To: opensocial-an...@googlegroups.com

Cc: Marco Ensing