proposal: Activity recipient control
2 views
Skip to first unread message
Eiji Kitamura
Oct 1, 2008, 11:50:02 AM10/1/08
to opensocial-an...@googlegroups.com
Hi folks,
Here I propose which I think is a fundamental element for social web communication.
Being social means there's privacy. You have your own data and control over it. You have your choice of sharing the data with someone you know, or anyone in public.
For example, you take a picture of your kid. Let's share it on a photo service. The photo service is integrated something like "Friend Connect" or "Data Availability" etc, so you can import your friend list from arbitrary SNS.
Now, who do you want to share your pic with? What if you don't want to share it with anyone but a part of your friends?
To do this, the service lets user choose a pic to share with, group or part of his friends to be shared with. Then, only people who are friends with the user and chosen will be able to see it.
I believe above is how social web works.
But there's one more important thing for social web, to "feedback activities" to SNS.
And here's the deal: OpenSocial only assumes activity which is public.
What if you see your friend uploaded a new pic on activity stream but unable to see actual picture when you jump to the site? What if you wrote a blog entry and its title is visible on activity stream while you configured it hidden to public?
My proposal gives activities choice of privacy.
Here's JS API:
requestCreateActivity(activity, recipients, priority, opt_callback)
Here I propose which I think is a fundamental element for social web communication.
Being social means there's privacy. You have your own data and control over it. You have your choice of sharing the data with someone you know, or anyone in public.
For example, you take a picture of your kid. Let's share it on a photo service. The photo service is integrated something like "Friend Connect" or "Data Availability" etc, so you can import your friend list from arbitrary SNS.
Now, who do you want to share your pic with? What if you don't want to share it with anyone but a part of your friends?
To do this, the service lets user choose a pic to share with, group or part of his friends to be shared with. Then, only people who are friends with the user and chosen will be able to see it.
I believe above is how social web works.
But there's one more important thing for social web, to "feedback activities" to SNS.
And here's the deal: OpenSocial only assumes activity which is public.
What if you see your friend uploaded a new pic on activity stream but unable to see actual picture when you jump to the site? What if you wrote a blog entry and its title is visible on activity stream while you configured it hidden to public?
My proposal gives activities choice of privacy.
Here's JS API:
requestCreateActivity(activity, recipients, priority, opt_callback)
Parameters:
opensocial.Activity activity - The activity to createArray<String>, String recipients
- An ID, array of IDs, or a group reference; a single ID within one of those groupsopensocial.CreateActivityPriority priority - The priority for this requestFunction opt_callback - The function to call once the request has been processed.RESTful API(XML):
<activity xmlns="http://ns.opensocial.org/2008/opensocial">
<id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778</id>
<recipient>example.org:AD38B3886625AAF</recipient>
<recipient>example.org:997638BAA6F25AD</recipient>
<title><a href=\"foo\">some activity</a></title>
<updated>2008-02-20T23:35:37.266Z</updated>
<body>Some details for some activity</body>
<bodyId>383777272</bodyId>
<url>http://api.example.org/activity/feeds/.../af3778</url>
<userId>example.org:34KJDCSKJN2HHF0DW20394</userId>
</activity>
RESTful API(Atom):
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:osapi="http://opensocial.org/2008/opensocialapi"> <category term="status"/> <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778</id> <osapi:recipient>example.org:AD38B3886625AAF</osapi:recipient> <ospai:recipient>example.org:997638BAA6F25AD</osapi:recipient>
<title><a href="foo">some activity</a></title> <summary>Some details for some activity</summary> <updated>2008-02-20T23:35:37.266Z</updated> <link rel="self" type="application/atom+xml" href="http://api.example.org/activity/feeds/.../af3778"/> <author><uri>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</uri></author> <content> <activity xmlns="http://ns.opensocial.org/2008/opensocial"> <body_id>383777272</bodyId> <activity> </content> </entry>
yoichiro
Oct 2, 2008, 5:34:01 AM10/2/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
Hi Eiji,
I'm understanding that the purpose of an activity stream is to publish
my actions for other users(ex. my friends) only. Therefore, the
activity becomes an important engine for finding a new application by
many users.
But I'm afraid it decreases the chance that many users discovers a new
application by your proposal. The activity stream is like a blog feed,
and it should not have scope, I think.
I seem the target users which you want to share your content is
determined at runtime, and it differs among contents. Well, I think
that a requestSendMessage function is suitable for your porpose.
I would like to hear other people's opinions.
Best regards,
Yoichiro
> *Here's JS API:**
> *requestCreateActivity(activity, *recipients*, priority, opt_callback)*
> *
> Parameters:**
> *opensocial.Activity* activity - The
> activity<http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/op...>
> to
> create**
> *Array<String>, String recipients - An ID, array of IDs, or a group
> reference; a single ID within one of those groups*
> *opensocial.CreateActivityPriority* priority - The
> priority<http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/op...>
> for
> this request**
> *Function* opt_callback - The function to call once the request has been
> processed.
>
> RESTful API(XML):
>
> *<activity xmlns="http://ns.opensocial.org/2008/opensocial">
I'm understanding that the purpose of an activity stream is to publish
my actions for other users(ex. my friends) only. Therefore, the
activity becomes an important engine for finding a new application by
many users.
But I'm afraid it decreases the chance that many users discovers a new
application by your proposal. The activity stream is like a blog feed,
and it should not have scope, I think.
I seem the target users which you want to share your content is
determined at runtime, and it differs among contents. Well, I think
that a requestSendMessage function is suitable for your porpose.
I would like to hear other people's opinions.
Best regards,
Yoichiro
> *requestCreateActivity(activity, *recipients*, priority, opt_callback)*
> *
> Parameters:**
> *opensocial.Activity* activity - The
> activity<http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/op...>
> to
> create**
> *Array<String>, String recipients - An ID, array of IDs, or a group
> reference; a single ID within one of those groups*
> *opensocial.CreateActivityPriority* priority - The
> priority<http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/op...>
> for
> this request**
> *Function* opt_callback - The function to call once the request has been
> processed.
>
> RESTful API(XML):
>
> *<activity xmlns="http://ns.opensocial.org/2008/opensocial">
> <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778</id>
> <recipient>example.org:AD38B3886625AAF</recipient>
> <recipient>example.org:997638BAA6F25AD</recipient>
> <title><a href=\"foo\">some activity</a></title>
> <updated>2008-02-20T23:35:37.266Z</updated>
> <body>Some details for some activity</body>
> <bodyId>383777272</bodyId>
> <url>http://api.example.org/activity/feeds/.../af3778</url>
> <userId>example.org:34KJDCSKJN2HHF0DW20394</userId>
> </activity>*
> <recipient>example.org:AD38B3886625AAF</recipient>
> <recipient>example.org:997638BAA6F25AD</recipient>
> <title><a href=\"foo\">some activity</a></title>
> <updated>2008-02-20T23:35:37.266Z</updated>
> <body>Some details for some activity</body>
> <bodyId>383777272</bodyId>
> <url>http://api.example.org/activity/feeds/.../af3778</url>
> <userId>example.org:34KJDCSKJN2HHF0DW20394</userId>
>
> RESTful API(Atom):
>
> <entry xmlns="http://www.w3.org/2005/Atom"
> xmlns:osapi="http://opensocial.org/2008/opensocialapi">
> <category term="status"/>
> <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778</id>*
> RESTful API(Atom):
>
> <entry xmlns="http://www.w3.org/2005/Atom"
> xmlns:osapi="http://opensocial.org/2008/opensocialapi">
> <category term="status"/>
> <osapi:recipient>example.org:AD38B3886625AAF</osapi:recipient>
> <ospai:recipient>example.org:997638BAA6F25AD</osapi:recipient>*
Eiji Kitamura
Oct 2, 2008, 10:10:07 PM10/2/08
to opensocial-an...@googlegroups.com
I forgot to write something important.
Activity recipient control is an *option*. If nothing is specified (or
null is specified) for recipients, the activity will be public.
The idea here is to prevent activity viewer's confusion. When the
content is access restricted, activity shouldn't be visible to anyone
who is unable to see it.
Let me pick up another example of bookmark sharing:
1. Here's a bookmark service which can import social graph from SNS.
2. User A bookmarks a page with restriction: only friend B can see his bookmark.
3. B finds A's bookmark on his activity stream. B can see the
bookmark's title and link. So he can actually visit the site.
4. What if friend C finds A's bookmark on his activity stream? It's
just bookmark so, C can visit the site. But that's not what A wanted.
What if the site is public but hidden like Picasa's private photo
page?
Activity stream is like RSS aggregation. But current OpenSocial spec
only allows public feeds to be aggreageed. The good thing about being
social is to be able to change visible information depending on the
person viewing it.
This spec suits better on RESTful protocol use case than on gadgets I believe.
> But I'm afraid it decreases the chance that many users discovers a new
> application by your proposal. The activity stream is like a blog feed,
> and it should not have scope, I think.
The purpose of activity stream is to let friends know what you're up
to, not what application you are using.
Using message is not suitable for distributing your activity.
2008/10/2 yoichiro <yoic...@eisbahn.jp>
yoichiro
Oct 7, 2008, 9:27:32 PM10/7/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
Hi Eiji,
I understood your proposal. Certainly, the restricted scope of an
activity is needed for the social. I basically agree it. +1. :)
I think that the argument 'recipients' cannot be omitted and not
permit null. Is my idea correct?
Best regards,
Yoichiro
> 2008/10/2 yoichiro <yoich...@eisbahn.jp>
I understood your proposal. Certainly, the restricted scope of an
activity is needed for the social. I basically agree it. +1. :)
I think that the argument 'recipients' cannot be omitted and not
permit null. Is my idea correct?
Best regards,
Yoichiro
Scott Seely
Oct 8, 2008, 11:18:09 AM10/8/08
to opensocial-an...@googlegroups.com
As this is developing towards something that we could cut/paste into a
spec, I'd like to suggest that we make visibility a required parameter
and default to having any activities be 'private'/visible to owner only.
It's a simple choice to make for the developer and can prevent
accidentally pushing things out to the world.
-Scott
spec, I'd like to suggest that we make visibility a required parameter
and default to having any activities be 'private'/visible to owner only.
It's a simple choice to make for the developer and can prevent
accidentally pushing things out to the world.
-Scott
Scott Seely
Oct 8, 2008, 4:45:41 PM10/8/08
to opensocial-an...@googlegroups.com
-1
Looking at this a bit more, I'm not convinced that this should be part
of OpenSocial. The security models that a social network uses to say who
can see what are typically part of the value add of that network. It's
why people stay engaged with one network over another, and one size does
not fit all.
It's a good idea, but should probably be implemented as part of your
larger offering. It feels like this idea is out of scope for OpenSocial.
Looking at this a bit more, I'm not convinced that this should be part
of OpenSocial. The security models that a social network uses to say who
can see what are typically part of the value add of that network. It's
why people stay engaged with one network over another, and one size does
not fit all.
It's a good idea, but should probably be implemented as part of your
larger offering. It feels like this idea is out of scope for OpenSocial.
gabrie...@gmail.com
Oct 16, 2008, 6:06:15 AM10/16/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
> Looking at this a bit more, I'm not convinced that this should be part
Data is more and more shared between social network. So in REST we
must find
a way to give the information of what could be shared, stored,
visible.
Example: I'm registered on a social web site, I share my data with a
forum.
As a user, I agree to share my birth date with this forum (to check
that I'm 18y.o),
but I don't want to make it visible to other users. I accept on this
forum to display
my MSN, ICQ, xxx, but only with registered people.
These data belong to the user and if we want to share these data with
other sites, we must
find a way to share what privacy the user want on each of these data.
Example
Job [1], private (don't want to share this info, even when exporting
my data)
birth date, friends (show only to my friends)
location, public (I want to display this information.)
But these privacy settings could be quite complicated.
Gab
Eiji Kitamura
Oct 16, 2008, 10:32:06 AM10/16/08
to opensocial-an...@googlegroups.com
Hi Scott,
> Looking at this a bit more, I'm not convinced that this should be part
> of OpenSocial. The security models that a social network uses to say who
> can see what are typically part of the value add of that network.
I agree, the security model itself is part of value add of the network.
But why should it notify inaccessible update information to other service?
This spec only gives a chance for networks to choose who to notify activity.
And it's just an option.
> It's a good idea, but should probably be implemented as part of your
> larger offering. It feels like this idea is out of scope for OpenSocial.
I believe it's quite generic idea on social sites to choose who to
share information.
Social is all about relationship between people.
The good thing about being social is :
* being able to share information easily with your connected people
* being able to collect your friends' recent activity at a glance
* being able to choose privacy level depending on who to share
OpenSocial gives privacy choice on output. But why not on input?
Eiji
Scott Seely
Oct 16, 2008, 10:55:13 AM10/16/08
to opensocial-an...@googlegroups.com
Eiji,
Good points.
After going through things and thinking a bit (I've been doing this
before your response;)), it seems that we already have a mechanism to
broadcast data to a restricted list: opensocial.Message. Activity is for
more general publication.
It seems that your changes really just turn Activity into a Message.
Granted, the data shows up in different ways, but the primary goal seems
to be 'tell a restricted list about something' which Message does quite
well.
Good points.
After going through things and thinking a bit (I've been doing this
before your response;)), it seems that we already have a mechanism to
broadcast data to a restricted list: opensocial.Message. Activity is for
more general publication.
It seems that your changes really just turn Activity into a Message.
Granted, the data shows up in different ways, but the primary goal seems
to be 'tell a restricted list about something' which Message does quite
well.
Eiji Kitamura
Oct 16, 2008, 11:31:16 AM10/16/08
to opensocial-an...@googlegroups.com
> After going through things and thinking a bit (I've been doing this
> before your response;)), it seems that we already have a mechanism to
> broadcast data to a restricted list: opensocial.Message. Activity is for
> more general publication.
>
> It seems that your changes really just turn Activity into a Message.
> Granted, the data shows up in different ways, but the primary goal seems
> to be 'tell a restricted list about something' which Message does quite
> well.
> before your response;)), it seems that we already have a mechanism to
> broadcast data to a restricted list: opensocial.Message. Activity is for
> more general publication.
>
> It seems that your changes really just turn Activity into a Message.
> Granted, the data shows up in different ways, but the primary goal seems
> to be 'tell a restricted list about something' which Message does quite
> well.
OK. In terms of multi-casting specific text, message and activity
stream seems to be the same.
Then, what is the difference?
In opensocial, message defines 4 types. Email, Private Message, Public
Message, Notification.
The common characteristics of them are "catching user's attension",
and "never disappear unless user explicitly indicates".
Then, what about activity stream?
Activity stream flows like feeds and not catching attension as much
like messages.
Activity stream pushes out old ones when newer comes.
The difference between message and activity stream resembles something
between RSS and email, i would say.
Would you like to receive your friends' blog update on email?
I wouldn't :)
Kevin Marks
Oct 16, 2008, 12:01:36 PM10/16/08
to opensocial-an...@googlegroups.com
On Thu, Oct 16, 2008 at 7:32 AM, Eiji Kitamura <age...@gmail.com> wrote:
Hi Scott,
I agree, the security model itself is part of value add of the network.
> Looking at this a bit more, I'm not convinced that this should be part
> of OpenSocial. The security models that a social network uses to say who
> can see what are typically part of the value add of that network.
But why should it notify inaccessible update information to other service?
This spec only gives a chance for networks to choose who to notify activity.
And it's just an option.
It shouldn't.
A key point of OpenSocial is that managing the complexity of who gets to see what is delegated to the Containers by the App. If every App has to manage the authorization model, OpenSocial gets way more complicated, the Apps get more complicated, adn the chance of personal data going astray goes up, not down.
> It's a good idea, but should probably be implemented as part of your> larger offering. It feels like this idea is out of scope for OpenSocial.I believe it's quite generic idea on social sites to choose who to
share information.
Social is all about relationship between people.
The good thing about being social is :
* being able to share information easily with your connected people
* being able to collect your friends' recent activity at a glance
* being able to choose privacy level depending on who to share
Exactly - doing that well for lots of users is complex, so being able to re-use that work as an app developer without having to implement it yourself is a good thing.
OpenSocial gives privacy choice on output. But why not on input?
As Scott says, the difference between message and activity show the difference of scope. Deciding which activities to show to whom based on a derived user model that makes users happy is what containers do.
Scott Seely
Oct 16, 2008, 12:53:35 PM10/16/08
to opensocial-an...@googlegroups.com
My point is this: if I need to pick out who receives a particular bit of
text/images on a case by case basis-- that's email. If I want to blog,
that's pushing to everyone.
Examples around the same event:
My wife and I just had a baby girl. 8 pounds, 4 ounces, 22 inches tall,
named Cassandra. <-- blog
I passed out when asked to cut the umbilical cord. I am now nursing a
mild concussion. <-- e-mail to select list.
I can see asking for a feature where the activity stream for a given
application has a select set of readers. For example, I don't want my
boss reading about how many fantasy football trades I make during work
hours. As a result, I only see benefit on setting viewer capabilities on
an activity stream, not on a single activity.
text/images on a case by case basis-- that's email. If I want to blog,
that's pushing to everyone.
Examples around the same event:
My wife and I just had a baby girl. 8 pounds, 4 ounces, 22 inches tall,
named Cassandra. <-- blog
I passed out when asked to cut the umbilical cord. I am now nursing a
mild concussion. <-- e-mail to select list.
I can see asking for a feature where the activity stream for a given
application has a select set of readers. For example, I don't want my
boss reading about how many fantasy football trades I make during work
hours. As a result, I only see benefit on setting viewer capabilities on
an activity stream, not on a single activity.
Eiji Kitamura
Oct 16, 2008, 12:57:58 PM10/16/08
to opensocial-an...@googlegroups.com
Hi Kevin,
> It shouldn't.
> A key point of OpenSocial is that managing the complexity of who gets to see
> what is delegated to the Containers by the App. If every App has to manage
> the authorization model, OpenSocial gets way more complicated, the Apps get
> more complicated, adn the chance of personal data going astray goes up, not
> down.
I understand that opensocial manages complexity for the sake of applications.
But as I've mentioned earlier, my proposal adapts more on external
application than gadget application. In other words, RESTful API is
assumed to be used more than JS API for this.
External applications are outside container's control, so they have to
deal with complexity anyway.
Think about architecture on DataAvailability, FriendConnect (I don't
know as much as you may know, though :P)
>> OpenSocial gives privacy choice on output. But why not on input?
>
> As Scott says, the difference between message and activity show the
> difference of scope. Deciding which activities to show to whom based on a
> derived user model that makes users happy is what containers do.
As I mentioned above, even if container is the one who decides which
activities to show, it has to know who to share if application is
external. This proposal gives a way to accomplish this.
Eiji Kitamura
Oct 16, 2008, 2:19:11 PM10/16/08
to opensocial-an...@googlegroups.com
> I can see asking for a feature where the activity stream for a given
> application has a select set of readers. For example, I don't want my
> boss reading about how many fantasy football trades I make during work
> hours. As a result, I only see benefit on setting viewer capabilities on
> an activity stream, not on a single activity.
> application has a select set of readers. For example, I don't want my
> boss reading about how many fantasy football trades I make during work
> hours. As a result, I only see benefit on setting viewer capabilities on
> an activity stream, not on a single activity.
I think your idea is one of the solutions for accomplishing my aim.
But wait, there must be various demand. Doesn't anybody need activity
receipent control per each activity?
I don't know what restrictions or guide lines DataAvailability exactly
have, but once integrated site receives social graph out of MySpace,
they can use it for example, as privacy restriction scope, don't they?
Do you want its activity public?
I'd like to hear more opinions from application developers regarding this.
Kevin Marks
Oct 16, 2008, 2:21:51 PM10/16/08
to opensocial-an...@googlegroups.com
On Thu, Oct 16, 2008 at 9:57 AM, Eiji Kitamura <age...@gmail.com> wrote:
Hi Kevin,
I understand that opensocial manages complexity for the sake of applications.
> It shouldn't.
> A key point of OpenSocial is that managing the complexity of who gets to see
> what is delegated to the Containers by the App. If every App has to manage
> the authorization model, OpenSocial gets way more complicated, the Apps get
> more complicated, adn the chance of personal data going astray goes up, not
> down.
But as I've mentioned earlier, my proposal adapts more on external
application than gadget application. In other words, RESTful API is
assumed to be used more than JS API for this.
External applications are outside container's control, so they have to
deal with complexity anyway.
No, through OAuth, the Container knows on whose behalf the request is being made, and so can constrain the info returned accordingly. The key difference is that in Request* APIs inside a Gadget, there is a opportunity for the Container to put up UI for the user, whereas for REST Activity stream API calls, the user may not be present, and so can't make additional choices.
Containers can choose to apply defaults, set up options at the Auth point, or defer interaction until the user next logs in.
Think about architecture on DataAvailability, FriendConnect (I don't
know as much as you may know, though :P)
As I mentioned above, even if container is the one who decides which
>> OpenSocial gives privacy choice on output. But why not on input?
>
> As Scott says, the difference between message and activity show the
> difference of scope. Deciding which activities to show to whom based on a
> derived user model that makes users happy is what containers do.
activities to show, it has to know who to share if application is
external. This proposal gives a way to accomplish this.
But you're presuming that the external application knows this and has constructed UI for it; that is a big assumption.
Eiji Kitamura
Oct 21, 2008, 6:54:19 AM10/21/08
to opensocial-an...@googlegroups.com
Hi Kevin,
> No, through OAuth, the Container knows on whose behalf the request is being
> made, and so can constrain the info returned accordingly.
Through OAuth, yes, the container knows on whose behalf the request is
being made, but it is not directly related to whom the activity is
visibile. Visibility is just an attribute of the activity.
> The key difference
> is that in Request* APIs inside a Gadget, there is a opportunity for the
> Container to put up UI for the user, whereas for REST Activity stream API
> calls, the user may not be present, and so can't make additional choices.
>
> Containers can choose to apply defaults, set up options at the Auth point,
> or defer interaction until the user next logs in.
I'm fine if i can accomplish what i want, but you don't sound like
giving me right clue. Do you mean that user can choose restriction
level on OAuth dance phase?
Mapping recipient control on OAuth sounds rediculous. They should be separate.
>> As I mentioned above, even if container is the one who decides which
>> activities to show, it has to know who to share if application is
>> external. This proposal gives a way to accomplish this.
>
> But you're presuming that the external application knows this and has
> constructed UI for it; that is a big assumption.
Defining APIs always need some extent of assumption. External services
(using REST API) have to create their own UI when showing friends list
etc anyway.
REST API is just API. UI design should be up to the consumer.
The UI I'm assuming resembles to what you can see at vox.com.
Say Vox.com can integrate with external SNS.
If they could import social graph out of for example Orkut, you can
write blog post to your Orkut friends.
Vox.com already has ability to share your blog post only with certain
friends like neighbors, friends, families for each entries. So you can
make the post visible only to part of Orkut friends if they are logged
into Vox.com and Orkut (using OAuth) at the same time.
On the other hand, on Orkut, the ideal is that your friends can see
your blog posts on their activity stream if it's visible also on
Vox.com.
To accomplish this, I need API to control recepient of activities.
Eiji Kitamura
Oct 21, 2008, 7:11:12 AM10/21/08
to opensocial-an...@googlegroups.com
Here's some changes to my proposal
For recipients, old proposal include ID, array of IDs, or a group. But I'd like to change this to only accept single group ID:
My original intension was this new spec, but to make it more flexible, I've added to support single IDs before posting.
Taking Kevin's advice, I'd like to bring it back to original spec, to lead developers easily imagine how they can construct UI.
For recipients, old proposal include ID, array of IDs, or a group. But I'd like to change this to only accept single group ID:
My original intension was this new spec, but to make it more flexible, I've added to support single IDs before posting.
Taking Kevin's advice, I'd like to bring it back to original spec, to lead developers easily imagine how they can construct UI.
> Here's JS API:
> requestCreateActivity(activity, recipients, priority, opt_callback)
> Parameters:
> opensocial.Activity activity - The activity to create
> Array<String>, String recipients - An ID, array of IDs, or a group reference; a single ID within one of those groups
String recipients - A group reference; a single ID within one of those groups
> opensocial.CreateActivityPriority priority - The priority for this request
> Function opt_callback - The function to call once the request has been processed.
>
> RESTful API(XML):
>
> <activity xmlns="http://ns.opensocial.org/2008/opensocial">
>
> <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778</id>
> <recipient>example.org:AD38B3886625AAF</recipient>
<recipient>example.org:AD38B3886625AAF/friends</recipient>
> <title><a href=\"foo\">some activity</a></title>
> <updated>2008-02-20T23:35:37.266Z</updated>
> <body>Some details for some activity</body>
> <bodyId>383777272</bodyId>
> <url>http://api.example.org/activity/feeds/.../af3778</url>
> <userId>example.org:34KJDCSKJN2HHF0DW20394</userId>
> </activity>
>
> RESTful API(Atom):
>
> <entry xmlns="http://www.w3.org/2005/Atom"
> xmlns:osapi="http://opensocial.org/2008/opensocialapi">
> <category term="status"/>
>
> <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778</id>
> <osapi:recipient>example.org:AD38B3886625AAF</osapi:recipient>
<osapi:recipient>example.org:AD38B3886625AAF/friends</osapi:recipient>
Scott Seely
Oct 27, 2008, 4:16:21 PM10/27/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
Are there any votes for/against this?
On Oct 21, 4:11 am, "Eiji Kitamura" <agek...@gmail.com> wrote:
> Here's some changes to my proposal
>
> For recipients, old proposal include ID, array of IDs, or a group. But I'd
> like to change this to only accept single group ID:
>
> My original intension was this new spec, but to make it more flexible, I've
> added to support single IDs before posting.
> Taking Kevin's advice, I'd like to bring it back to original spec, to lead
> developers easily imagine how they can construct UI.
>
> > Here's JS API:
> > requestCreateActivity(activity, recipients, priority, opt_callback)
> > Parameters:
> > opensocial.Activity activity - The activity to create
> > Array<String>, String recipients - An ID, array of IDs, or a group
>
> reference; a single ID within one of those groups
> *String recipients - A group reference; a single ID within one of those
> groups*
On Oct 21, 4:11 am, "Eiji Kitamura" <agek...@gmail.com> wrote:
> Here's some changes to my proposal
>
> For recipients, old proposal include ID, array of IDs, or a group. But I'd
> like to change this to only accept single group ID:
>
> My original intension was this new spec, but to make it more flexible, I've
> added to support single IDs before posting.
> Taking Kevin's advice, I'd like to bring it back to original spec, to lead
> developers easily imagine how they can construct UI.
>
> > Here's JS API:
> > requestCreateActivity(activity, recipients, priority, opt_callback)
> > Parameters:
> > opensocial.Activity activity - The activity to create
> > Array<String>, String recipients - An ID, array of IDs, or a group
>
> reference; a single ID within one of those groups
> groups*
>
> > opensocial.CreateActivityPriority priority - The priority for this request
> > Function opt_callback - The function to call once the request has been
> processed.
>
> > RESTful API(XML):
>
> > <activity xmlns="http://ns.opensocial.org/2008/opensocial">
>
> > <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778
> </id>
> > <recipient>example.org:AD38B3886625AAF</recipient>
>
> *<recipient>example.org:AD38B3886625AAF/friends</recipient>*
> > opensocial.CreateActivityPriority priority - The priority for this request
> > Function opt_callback - The function to call once the request has been
> processed.
>
> > RESTful API(XML):
>
> > <activity xmlns="http://ns.opensocial.org/2008/opensocial">
>
> > <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778
> </id>
> > <recipient>example.org:AD38B3886625AAF</recipient>
>
>
>
>
> > <title><a href=\"foo\">some activity</a></title>
> > <updated>2008-02-20T23:35:37.266Z</updated>
> > <body>Some details for some activity</body>
> > <bodyId>383777272</bodyId>
> > <url>http://api.example.org/activity/feeds/.../af3778</url>
> > <userId>example.org:34KJDCSKJN2HHF0DW20394</userId>
> > </activity>
>
> > RESTful API(Atom):
>
> > <entry xmlns="http://www.w3.org/2005/Atom"
> > xmlns:osapi="http://opensocial.org/2008/opensocialapi">
> > <category term="status"/>
>
> > <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778
> </id>
> > <osapi:recipient>example.org:AD38B3886625AAF</osapi:recipient>
>
> *<osapi:recipient>example.org:AD38B3886625AAF/friends</osapi:recipient>*
>
>
> > <title><a href=\"foo\">some activity</a></title>
> > <updated>2008-02-20T23:35:37.266Z</updated>
> > <body>Some details for some activity</body>
> > <bodyId>383777272</bodyId>
> > <url>http://api.example.org/activity/feeds/.../af3778</url>
> > <userId>example.org:34KJDCSKJN2HHF0DW20394</userId>
> > </activity>
>
> > RESTful API(Atom):
>
> > <entry xmlns="http://www.w3.org/2005/Atom"
> > xmlns:osapi="http://opensocial.org/2008/opensocialapi">
> > <category term="status"/>
>
> > <id>http://example.org/activities/example.org:87ead8dead6beef/self/af3778
> </id>
> > <osapi:recipient>example.org:AD38B3886625AAF</osapi:recipient>
>
Chris Chabot
Nov 2, 2008, 8:13:38 AM11/2/08
to opensocial-an...@googlegroups.com
I'm +1 on this.
Ps, did we already start the official voting rounds then? :)
-- Chris
Ps, did we already start the official voting rounds then? :)
-- Chris
Scott Seely
Nov 17, 2008, 4:33:12 PM11/17/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
Updating thread with notes from F2F:
Security per activity stream isn't something that all containers
support. The consensus at the meeting was that we could add a well-
known named parameter to add to opt_params which takes an idspec.
Containers that want to support recipient control can handle the
parameter. Other containers will ignore the parameter. The proposal
needs to be updated to show how this would also work for REST.
Security per activity stream isn't something that all containers
support. The consensus at the meeting was that we could add a well-
known named parameter to add to opt_params which takes an idspec.
Containers that want to support recipient control can handle the
parameter. Other containers will ignore the parameter. The proposal
needs to be updated to show how this would also work for REST.
Scott Seely
Nov 19, 2008, 3:33:12 PM11/19/08
to opensocial-an...@googlegroups.com, Eiji Kitamura
Eiji,
Can you comment on the request for the proposal?
> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-
> and-gadg...@googlegroups.com] On Behalf Of Scott Seely
> Sent: Monday, November 17, 2008 1:33 PM
> To: OpenSocial - OpenSocial and Gadgets Specification Discussion
> Subject: [opensocial-and-gadgets-spec] Re: proposal: Activity recipient
> control
>
>
Can you comment on the request for the proposal?
> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-
> and-gadg...@googlegroups.com] On Behalf Of Scott Seely
> Sent: Monday, November 17, 2008 1:33 PM
> To: OpenSocial - OpenSocial and Gadgets Specification Discussion
> Subject: [opensocial-and-gadgets-spec] Re: proposal: Activity recipient
> control
>
>
Eiji Kitamura
Nov 20, 2008, 2:39:40 AM11/20/08
to opensocial-an...@googlegroups.com
Hi all,
After receiving feedback, I'm trying to revise my proposal.
When working on it, I've come to wondering why requestCreateActivity
is not part of DataRequest?
Why not having requestCreateActivity like "newAddActivityRequest"
under DataRequest?
opensocial.requestCreateAcitivity does not seem to live on right place.
For example, fetching activities is already part of DataRequest like
newFetchActivitiesRequest.
How about moving opensocial.CreateActivityPriority to like
opensocial.DataRequest.ActivityPriority? which also looks outstanding
on opensocial object.
Then, opensocial.DataRequest.ActivityFields will also be required,
which my proposal will fit confortably as
opensocial.DataRequest.ActivityFields.RECIPIENT.
This will be a significant change to opensocial spec and requires me
some extent of time to make draft
proposal since I'm working on this on my spare time.
I'll keep working on this but, let me hear if moving CreateActivity to
DataRequest is something valuable to work on.
Otherwise, I'll switch over to just making revised proposal of
Activity Recipient Control.
Thanks,
2008/11/20 Scott Seely <sSe...@myspace.com>:
After receiving feedback, I'm trying to revise my proposal.
When working on it, I've come to wondering why requestCreateActivity
is not part of DataRequest?
Why not having requestCreateActivity like "newAddActivityRequest"
under DataRequest?
opensocial.requestCreateAcitivity does not seem to live on right place.
For example, fetching activities is already part of DataRequest like
newFetchActivitiesRequest.
How about moving opensocial.CreateActivityPriority to like
opensocial.DataRequest.ActivityPriority? which also looks outstanding
on opensocial object.
Then, opensocial.DataRequest.ActivityFields will also be required,
which my proposal will fit confortably as
opensocial.DataRequest.ActivityFields.RECIPIENT.
This will be a significant change to opensocial spec and requires me
some extent of time to make draft
proposal since I'm working on this on my spare time.
I'll keep working on this but, let me hear if moving CreateActivity to
DataRequest is something valuable to work on.
Otherwise, I'll switch over to just making revised proposal of
Activity Recipient Control.
Thanks,
2008/11/20 Scott Seely <sSe...@myspace.com>:
yoichiro
Nov 20, 2008, 3:23:57 AM11/20/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
Hi Eiji,
I think that moving the place of createActivity() function is
incorrect.
After calling the function of opensocial.*, the callback function
passed to the argument will be called, or your application will be
reload from scratch. In addition, when you call the
requestCreateActivity() function, the dialog to input something might
open. I think, therefore, this behavior is not match the sequence
using opensocial.DataRequest.
Thanks,
Yoichiro
I think that moving the place of createActivity() function is
incorrect.
After calling the function of opensocial.*, the callback function
passed to the argument will be called, or your application will be
reload from scratch. In addition, when you call the
requestCreateActivity() function, the dialog to input something might
open. I think, therefore, this behavior is not match the sequence
using opensocial.DataRequest.
Thanks,
Yoichiro
Eiji Kitamura
Nov 20, 2008, 10:32:31 AM11/20/08
to opensocial-an...@googlegroups.com
Hi yoichiro,
> After calling the function of opensocial.*, the callback function
> passed to the argument will be called, or your application will be
> reload from scratch.
Sorry, I don't get what you mean.
> In addition, when you call the
> requestCreateActivity() function, the dialog to input something might
> open. I think, therefore, this behavior is not match the sequence
> using opensocial.DataRequest.
I guess you mean about requestPermission type thing when priority is
HIGH? which does not seem to be implemented on shindig?
This is another question here.
There's already a function called requestPermission. Why
requestCreateActivity calls it automatically while
newUpdateAppDataRequest or newFetchPeopleRequest, etc needs manual
invoke?
Can't we either of following?
1. remove automatic requestPermission on requestCreateActivity.
2. add automatic requestPermission to newUpdateAppDataRequest,
newFetchPeopleRequest, etc.
Does anyone know / have opinion about this?
> After calling the function of opensocial.*, the callback function
> passed to the argument will be called, or your application will be
> reload from scratch.
> In addition, when you call the
> requestCreateActivity() function, the dialog to input something might
> open. I think, therefore, this behavior is not match the sequence
> using opensocial.DataRequest.
HIGH? which does not seem to be implemented on shindig?
This is another question here.
There's already a function called requestPermission. Why
requestCreateActivity calls it automatically while
newUpdateAppDataRequest or newFetchPeopleRequest, etc needs manual
invoke?
Can't we either of following?
1. remove automatic requestPermission on requestCreateActivity.
2. add automatic requestPermission to newUpdateAppDataRequest,
newFetchPeopleRequest, etc.
Does anyone know / have opinion about this?
Louis Ryan
Nov 20, 2008, 11:25:54 AM11/20/08
to opensocial-an...@googlegroups.com
Eiji,
I think youre right to point out that theres some inconsistency here, however I think we need to retain requestCreateActivity. It's perfectly reasonable for a container to provider a DataRequest option to create activities though many containers would deny those requests because they don't allow for user confirmation. In situations where the gadget needs to request permission from the user to post the activity requestPermission doesnt quite cut it because it doesnt allow the user to review the contents of the activity, this is why requestCreateActivity and requestSendMessage look like they do, and why requestPermission.
Im generally in favor of extending the JS API to support activity creation as part of the normal request processing and I think this will occur as a natural consequence of the oslite proposal and so I would defer it to that.
-Louis
Eiji Kitamura
Nov 23, 2008, 8:31:48 AM11/23/08
to opensocial-an...@googlegroups.com
Hi Louis,
> In situations where the gadget needs to
> request permission from the user to post the activity requestPermission
> doesnt quite cut it because it doesnt allow the user to review the contents
> of the activity, this is why requestCreateActivity and requestSendMessage
> look like they do, and why requestPermission.
I think it's reasonable enough to have requestCreateActivity as it is
by seeing your comment.
I've revised my proposal but kept it as opensocial.requestCreateActivity.
Thank you for convincing me!
>> > After calling the function of opensocial.*, the callback function
>> > passed to the argument will be called, or your application will be
>> > reload from scratch.
I've talked to yoichiro in person and discussed about this.
But both of us couldn't find any reason why reloading application
after submitting activity is in spec.
To avoid spam? Does anyone know why?
> In situations where the gadget needs to
> request permission from the user to post the activity requestPermission
> doesnt quite cut it because it doesnt allow the user to review the contents
> of the activity, this is why requestCreateActivity and requestSendMessage
> look like they do, and why requestPermission.
by seeing your comment.
I've revised my proposal but kept it as opensocial.requestCreateActivity.
Thank you for convincing me!
>> > After calling the function of opensocial.*, the callback function
>> > passed to the argument will be called, or your application will be
>> > reload from scratch.
But both of us couldn't find any reason why reloading application
after submitting activity is in spec.
To avoid spam? Does anyone know why?
Eiji Kitamura
Nov 23, 2008, 8:35:53 AM11/23/08
to opensocial-an...@googlegroups.com
Hi all,
I've revised my proposal.
The point is following:
* opensocial.requestCreateActivity(activity, recipient, priority,
opt_callback) is now
opensocial.requestCreateActivity(activity, priority, opt_callback, opt_params)
* Added opensocial.CreateActivity object.
* Added opensocial.CreateActivity.Field (RECIPIENT, PRIORITY)
* Added opensocial.CreateActivity.PriorityType
* Deprecation of opensocial.CreateActivityPriority is part of my proposal
Please give me feedback so that i can make it better.
2008/11/23 Eiji Kitamura <age...@gmail.com>:
I've revised my proposal.
The point is following:
* opensocial.requestCreateActivity(activity, recipient, priority,
opt_callback) is now
opensocial.requestCreateActivity(activity, priority, opt_callback, opt_params)
* Added opensocial.CreateActivity object.
* Added opensocial.CreateActivity.Field (RECIPIENT, PRIORITY)
* Added opensocial.CreateActivity.PriorityType
* Deprecation of opensocial.CreateActivityPriority is part of my proposal
Please give me feedback so that i can make it better.
2008/11/23 Eiji Kitamura <age...@gmail.com>:
Eiji Kitamura
Nov 23, 2008, 8:36:56 AM11/23/08
to opensocial-an...@googlegroups.com
Eiji Kitamura
Nov 29, 2008, 8:48:16 AM11/29/08
to opensocial-an...@googlegroups.com
Hi all
While deadline for proposal voting getting close, my proposal doesn't
seem to have enough +1s.
To make it easier for people to understand what I'm proposing, I've
made a presentation on Google Docs.
http://docs.google.com/Presentation?id=dgmhc9s4_64ngvrndpn
Hope this will urge discussion and we can make it better.
I'm feeling that my proposal will be definately demanded eventually in
the future.
Eiji,
2008/11/23 Eiji Kitamura <age...@gmail.com>:
While deadline for proposal voting getting close, my proposal doesn't
seem to have enough +1s.
To make it easier for people to understand what I'm proposing, I've
made a presentation on Google Docs.
http://docs.google.com/Presentation?id=dgmhc9s4_64ngvrndpn
Hope this will urge discussion and we can make it better.
I'm feeling that my proposal will be definately demanded eventually in
the future.
Eiji,
2008/11/23 Eiji Kitamura <age...@gmail.com>:
Evan Gilbert
Dec 1, 2008, 11:07:02 AM12/1/08
to opensocial-an...@googlegroups.com
This functionality definitely will be needed, but I agree that many containers will have their own policies for activity visibility.
So I'm +1 as long as we make it a MAY and have a way for containers to expose whether they support this functionality.
Also note that requestCreateActivity() is intended to support this use case. I'd strongly encourage containers to provide a custom UI that lets users choose what users/groups to share with. This is possible today and allows for much more container flexibility than we will likely standardize in any data API.
Evan
So I'm +1 as long as we make it a MAY and have a way for containers to expose whether they support this functionality.
Also note that requestCreateActivity() is intended to support this use case. I'd strongly encourage containers to provide a custom UI that lets users choose what users/groups to share with. This is possible today and allows for much more container flexibility than we will likely standardize in any data API.
Evan
On Sat, Nov 29, 2008 at 5:48 AM, Eiji Kitamura <age...@gmail.com> wrote:
Hi all
While deadline for proposal voting getting close, my proposal doesn't
seem to have enough +1s.
To make it easier for people to understand what I'm proposing, I've
made a presentation on Google Docs.
Louis Ryan
Dec 1, 2008, 4:25:44 PM12/1/08
to opensocial-an...@googlegroups.com
Eiji,
There has been quite a bit of discussion on the other messaging thread https://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/12cf19ebc1886d5e/3e96527b0c1ab460 about the use of id's of the form
example.org:12345/friends
and people, myself included are -1 on doing this without a consistent relative id proposal. Im not sure how workable this proposal is until that is resolved?
-Louis
There has been quite a bit of discussion on the other messaging thread https://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/12cf19ebc1886d5e/3e96527b0c1ab460 about the use of id's of the form
example.org:12345/friends
and people, myself included are -1 on doing this without a consistent relative id proposal. Im not sure how workable this proposal is until that is resolved?
-Louis
Eiji Kitamura
Dec 2, 2008, 5:35:04 AM12/2/08
to opensocial-an...@googlegroups.com
Hi Louis,
> There has been quite a bit of discussion on the other messaging thread
> https://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/12cf19ebc1886d5e/3e96527b0c1ab460
> about the use of id's of the form
>
> example.org:12345/friends
>
> and people, myself included are -1 on doing this without a consistent
> relative id proposal. Im not sure how workable this proposal is until that
> is resolved?
You're right. I've been involved in that thread and wondering how I
can bring it into this proposal.
But the problem is that I'm not very clear what exactly is needed and
what is problem here.
I'll post further replies regarding this issue to that thread.
> There has been quite a bit of discussion on the other messaging thread
> https://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/12cf19ebc1886d5e/3e96527b0c1ab460
> about the use of id's of the form
>
> example.org:12345/friends
>
> and people, myself included are -1 on doing this without a consistent
> relative id proposal. Im not sure how workable this proposal is until that
> is resolved?
can bring it into this proposal.
But the problem is that I'm not very clear what exactly is needed and
what is problem here.
I'll post further replies regarding this issue to that thread.
Scott Seely
Dec 4, 2008, 8:17:34 AM12/4/08
to OpenSocial - OpenSocial and Gadgets Specification Discussion
This proposal is being moved to v.NEXT.
On Nov 20, 8:25 am, Louis Ryan <lr...@google.com> wrote:
> Eiji,
> I think youre right to point out that theres some inconsistency here,
> however I think we need to retain requestCreateActivity. It's perfectly
> reasonable for a container to provider a DataRequest option to create
> activities though many containers would deny those requests because they
> don't allow for user confirmation. In situations where the gadget needs to
> request permission from the user to post the activity requestPermission
> doesnt quite cut it because it doesnt allow the user to review the contents
> of the activity, this is why requestCreateActivity and requestSendMessage
> look like they do, and why requestPermission.
>
> Im generally in favor of extending the JS API to support activity creation
> as part of the normal request processing and I think this will occur as a
> natural consequence of the oslite proposal and so I would defer it to that.
>
> -Louis
>
On Nov 20, 8:25 am, Louis Ryan <lr...@google.com> wrote:
> Eiji,
> I think youre right to point out that theres some inconsistency here,
> however I think we need to retain requestCreateActivity. It's perfectly
> reasonable for a container to provider a DataRequest option to create
> activities though many containers would deny those requests because they
> don't allow for user confirmation. In situations where the gadget needs to
> request permission from the user to post the activity requestPermission
> doesnt quite cut it because it doesnt allow the user to review the contents
> of the activity, this is why requestCreateActivity and requestSendMessage
> look like they do, and why requestPermission.
>
> Im generally in favor of extending the JS API to support activity creation
> as part of the normal request processing and I think this will occur as a
> natural consequence of the oslite proposal and so I would defer it to that.
>
> -Louis
>
Reply all
Reply to author
Forward
0 new messages