Add Support for Groups

[asthabhat...@gmail.com]

Hi All,

I would like to propose a new API support in opensocial.

social/rest/groups/{userId}/

The groups may have following fields
1. Group name (title)
2. Group Id
3. Owner Id
4. Created by
5. Created at
6. total number of members

the group feature can be viewd as community feature on orkut, where
users used to create/join multiple groups. User may want to access
groups, group's activities, group users and may want to send message
to all the group members.

The equivalent Json calls would be like

opensocial.newCreateGroupRequest*(idSpec, Group)
opensocial.newFetchGroupRequest*(idSpec, Group)
opensocial.newDeleteGroupRequest*(idSpec, Group)
opensocial.newUpdateGroupRequest*(idSpec, Group)

a sample is implemeted for supporting Groups in shindig at
https://issues.apache.org/jira/browse/SHINDIG-626

Astha

[Scott Seely]

Added to the list of items for v.NEXT:
http://wiki.opensocial.org/index.php?title=V0.10_API_001

[Bess Ho]

+1

Group is another viral marketing tool. Good proposal.

[Eiji Kitamura]

Hi,

I like the idea of adding group functionality to OpenSocial. I would
have been going to propose similar one if you hadn't.
One thing, the term "group" is already taken to express when
aggregating part of friends.
I suggest you to use "community" instead of "group".
I will give +1 after looking closer.

btw, is this proposal for OpenSocial version 0.10?


2008/11/26 Bess Ho <bes...@gmail.com>

[Scott Seely]

Given where we are in the process, this proposal is v.NEXT (probably
0.10).

[Monica Keller]

I support this proposal. In fact I joined this forum only to request
for this to be added :)

A couple more fields to consider are:
-Category (is this a school group, an organization, a friend category,
an interest based group, etc)
-Privacy (Is this group public or not, can you show it to users who
are not members and eventually how much data can be shared)

App developers for Ning and MySpace will be super happy with the
feature of Groups in Opensocial

We absolutely need a way to share information without having to make
individuals "friends"

[Bess Ho]

Agree. I think we need to brainstorm the concept, use case, and features on group related API. Come up with an extensible design. Younger generation end-user are pretty much tired of email, one-to-one communication. Most users use social network to gather and distribute to small batch of users or friends.

About individual friend. Why this is not a preferred method. First of all containers limit many friends you can invite per app per day, limit feed, notification and email per app per day. Open Social don't have the most friendly UI to make inviting multiple friends easy for developers. It is much easier to add members to group for once and all and use group to share information.

--
Bess Ho

[David Glazer]

Something to consider in supporting groups/communities -- it would be nice if many of the existing methods which work on individual users (e.g. sendMessage, shareApp) could also work on groups of users.  So as we work through this proposal, let's see if we can find a clean way to let calls that accept one id also accept the other.  (One such way would be to define userId and groupId to live in the same namespace, but that's only one way.)

  - dG

2008/12/7 Bess Ho <bes...@gmail.com>

[Scott Seely]

FWIW, in the 0.9 iteration, we changed requestSendMessage and requestShareApp to take an IdSpec. An IdSpec allows for groups.

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of David Glazer
Sent: Sunday, December 07, 2008 9:08 AM
To: opensocial-and-gadgets-spec
Subject: [opensocial-and-gadgets-spec] Re: Add Support for Groups

 

Something to consider in supporting groups/communities -- it would be nice if many of the existing methods which work on individual users (e.g. sendMessage, shareApp) could also work on groups of users.  So as we work through this proposal, let's see if we can find a clean way to let calls that accept one id also accept the other.  (One such way would be to define userId and groupId to live in the same namespace, but that's only one way.)

[Sylvain Wallez]

Monica Keller wrote:
> I support this proposal. In fact I joined this forum only to request
> for this to be added :)
>
> A couple more fields to consider are:
> -Category (is this a school group, an organization, a friend category,
> an interest based group, etc)
> -Privacy (Is this group public or not, can you show it to users who
> are not members and eventually how much data can be shared)
>

I second the strong need for privacy settings. Groups can be used to
model the users with whom a gadget has been shared, thus enabling
private collaborative gadgets.

Think e.g. of a shopping list for the week-end bbq that you don't want
the whole world to know about!

Sylvain

--
Sylvain Wallez CTO, Goojet
http://bluxte.net http://www.goojet.com

[Eiji Kitamura]

As brain storming, I propose couple of ideas.

* community gadget:
if adding gadget to community page is possible, it's nice. Imagine you
have gadgets on google groups page. instead of fetching friends, you
can fetch members of the community using opensocial API, and so on.

* role:
administrator, mederator, etc are needed as member role.


Eiji,

2008/12/10 Sylvain Wallez <syl...@apache.org>:

[Dave]

Here are some thoughts on Group support in OpenSocial, based on what
we've got so far in Project SocialSite
(http://socialsite.dev.java.net).

SocialSite includes OpenSocial-style REST and RPC support for getting
lists of groups, group properties, updating group properties, inviting
members, accepting members, etc. Because everything is a Gadget in
SocialSite, we've set things up so that we can restrict usage of our
friending/group management extensions to only certain gadgets (e.g.
our dashboard gadget).

I'm not sure all that belongs in OpenSocial. Is there a consensus on
how much friending, group invite, group management and write-access to
the social graph should be included in OpenSocial? How much power
should a gadget have?

Either way, it does seem appropriate for OpenSocial to at least
include support for read-access to groups: getting lists of groups,
searching groups, getting a single group and getting a user's groups.
For example, these are the types of URIs we support:

/groups/@public
GET of all public groups
/groups/@public/{groupId}
GET of a given group
/groups/{userId}
GET of user's groups
/search/@groups/{terms}
GET search results

And we've got corresponding JavaScript APIs.

Our JavaScript Group object has these fields:
handle: unique identifier for group, suitable for use in URL
name: short name of group
description: longer description of group, its purpose, etc.
thumbnailUrl: URL of the group's logo
viewUrl: URL of the group's profile page
viewerRelationship: relationship of view to group (MEMBER, ADMIN, FOUNDER)

We'd like to have a pretty flexible group model. We have discussed
supporting these types of groups:

* Public/open: everybody can see group, anybody can join
* Public/closed: everybody can see, memberships must be approved
* Private/closed: hidden to public, invitation only
* Personal: hidden to public, use it to organize your friends

Currently, we support only public/closed. It would be best to have a
group model that can support all of those types of groups, and others
I might have missed.

- Dave

[Bess Ho]

It is a good proposal. I'll vote once it is available on v0.9. This will work well beyond consumer applications, to business, non-profit, and enterprise where groups are used in communications.

--
Bess Ho

[Scott Seely]

Just to be clear, 0.9 voting is done. This proposal will need to go into v.NEXT.

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Bess Ho
Sent: Thursday, December 11, 2008 1:11 PM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Add Support for Groups

 

It is a good proposal. I'll vote once it is available on v0.9. This will work well beyond consumer applications, to business, non-profit, and enterprise where groups are used in communications.

[Dave]

On Thu, Dec 11, 2008 at 5:35 PM, Scott Seely <sSe...@myspace.com> wrote:
> Just to be clear, 0.9 voting is done. This proposal will need to go into
> v.NEXT.

I'd like to get Group support into the JavaScript APIs so I'd like to
re-start this thread for 1.0.
Here's a pointer back to the old discussion:

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/8cd96d44660c3ec7

Here's the current status of groups:

The ability to get the Groups associated with a user is specified in
the REST proposal:
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.7.2

And, in the REST proposal a group is defined as follows:

<xs:complexType name="Group">
<xs:all>
<xs:element minOccurs="0" name="id" type="xs:string" />
<xs:element minOccurs="0" name="title" type="xs:string" />
</xs:all>
</xs:complexType>

However, this support for Groups is not mentioned in the JSON-RPC spec
or either of the JavaScript APIs.

I'd like to get Group support into the JavaScript APIs so that we have
parity here. I guess this means I need spec language for JSON-RPC, the
old JavaScript API, the new OSAPI and an implementation. Any comments
or concerns about this before I try to come up with those items?

Should I start by adding a DRAFT proposal page to the wiki and getting
it into the 1.0 table there?

Thanks,
Dave

[Chris Chabot]

There's been quite a few inquiries about groups support since we worked on 0.9, so I wouldn't mind reopening that discussion

[Lane LiaBraaten]

We define a groups endpoint for REST, so we should also have one for RPC, osapi.* and data pipelining.

-Lane

[Evan Gilbert]

To follow up on what Lane said - there is already a partial spec for groups in OpenSocial: http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.7.2. I wasn't aware of this so wanted to point it out, again.

Given that it is there already, think we have two good options:

1. If we just want to clarify what is there, maybe with small enhancements, and support RPC, osapi, etc., we should add this for 1.0.

2. If we want to significantly expand group functionality, we should probably use the extension process.

We can also do both. It sounds like Dave is interested in #1, and we should move forward. If we want to move forward with Ashta's original proposal on this thread, we should probably make it an official extension.

Evan

[Steve T]

I vote for an official extension to expand on group as a full entity.
The details currently in the spec don't go far enough IMHO.

Steve

On Sep 25, 8:50 pm, Evan Gilbert <uid...@google.com> wrote:
> To follow up on what Lane said - there is already a partial spec for groups

> in OpenSocial:http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RES....

> I wasn't aware of this so wanted to point it out, again.
> Given that it is there already, think we have two good options:
> 1. If we just want to clarify what is there, maybe with small enhancements,
> and support RPC, osapi, etc., we should add this for 1.0.
> 2. If we want to significantly expand group functionality, we should
> probably use the extension process.
>
> We can also do both. It sounds like Dave is interested in #1, and we should
> move forward. If we want to move forward with Ashta's original proposal on
> this thread, we should probably make it an official extension.
>
> Evan
>

> On Fri, Sep 25, 2009 at 10:10 AM, Lane LiaBraaten <lliab...@google.com>wrote:
>
> > We define a groups endpoint for REST, so we should also have one for RPC,
> > osapi.* and data pipelining.
>
> > -Lane
>

> > On Fri, Sep 25, 2009 at 10:07 AM, Chris Chabot <chab...@google.com> wrote:
>
> >> There's been quite a few inquiries about groups support since we worked on
> >> 0.9, so I wouldn't mind reopening that discussion
>

> >> On Fri, Sep 25, 2009 at 4:04 PM, Dave <snoopd...@gmail.com> wrote:
>
> >>> On Thu, Dec 11, 2008 at 5:35 PM, Scott Seely <sSe...@myspace.com> wrote:
> >>> > Just to be clear, 0.9 voting is done. This proposal will need to go
> >>> into
> >>> > v.NEXT.
>
> >>> I'd like to get Group support into the JavaScript APIs so I'd like to
> >>> re-start this thread for 1.0.
> >>> Here's a pointer back to the old discussion:
>

> >>>http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

>
> >>> Here's the current status of groups:
>
> >>> The ability to get the Groups associated with a user is specified in
> >>> the REST proposal:
>

> >>>http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/RES...

[Lane LiaBraaten]

On Sun, Sep 27, 2009 at 8:43 AM, Steve T <stephen....@lmco.com> wrote:

I vote for an official extension to expand on group as a full entity.
The details currently in the spec don't go far enough IMHO.

+1 - Given that the current  groups service is 1) vaguely specified 2) lacking the features in this thread, I think moving it into an extension is the right approach.  As an extension we can figure out the right features and semantics for the groups service, then add it back into the spec at a later date.  Any container that currently supports the groups service can continue to do so, but I don't think the group service as defined meets the maturity bar for inclusion in the core spec.

I've added a row to the proposals page: http://wiki.opensocial.org/index.php?title=Spec_Changes#Current_Status_At_a_Glance

-Lane

[Dave]

Hi Lane,

I agree that features that concern group creation, membership
management, etc. should be handled in an extension, but I feel pretty
strongly that basic group support should be present in the core
specification: the ability to get a list of the groups associated with
a user with fields id, title and description.

I wrote up my proposal here and have started a separate thread to discuss it:

http://wiki.opensocial.org/index.php?title=Complete_existing_basic_groups_support

Thanks,
- Dave