TOP_FRIENDS as a filter

13 views
Skip to first unread message

Paul Lindner

unread,
Apr 7, 2008, 6:17:48 PM4/7/08
to opensocial-an...@googlegroups.com
I'd like to see TOP_FRIENDS available as a filter as well as a sort
option.

Also, Where are we tracking these feature requests?


--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

Cassie

unread,
Apr 14, 2008, 7:58:01 AM4/14/08
to opensocial-an...@googlegroups.com
current proposal list:
http://spreadsheets.google.com/pub?key=pigtmOB55Aw_YJHz040u0Kg

spec change:

opensocial.DataRequest.FilterType = {
...
/**
* Retrieves only the user's top friends.
*
* @member opensocial.DataRequest.FilterType
*/
TOP_FRIENDS : 'topFriends',
...
}


votes/comments?

- Cassie

Zhen Wang

unread,
Apr 14, 2008, 3:01:05 PM4/14/08
to opensocial-an...@googlegroups.com
How is the top_friends ranking function defined? And does this filter
type imply that there's only one way to rank friends?

Paul Lindner

unread,
Apr 14, 2008, 3:29:44 PM4/14/08
to opensocial-an...@googlegroups.com
On Mon, Apr 14, 2008 at 12:01:05PM -0700, Zhen Wang wrote:
>
> How is the top_friends ranking function defined? And does this filter
> type imply that there's only one way to rank friends?

Different containers have different ways of delineating who is or is
not a top friend. At hi5 the user decides this.

Other containers may choose a decent list with a variable cutoff.

> On Mon, Apr 14, 2008 at 4:58 AM, Cassie <do...@google.com> wrote:
> >
> > current proposal list:
> > http://spreadsheets.google.com/pub?key=pigtmOB55Aw_YJHz040u0Kg
> >
> > spec change:
> >
> > opensocial.DataRequest.FilterType = {
> > ...
> > /**
> > * Retrieves only the user's top friends.
> > *
> > * @member opensocial.DataRequest.FilterType
> > */
> > TOP_FRIENDS : 'topFriends',
> > ...
> > }
> >
> >
> > votes/comments?
> >
> > - Cassie
> >
> >
> >
> > On Tue, Apr 8, 2008 at 12:17 AM, Paul Lindner <lin...@inuus.com> wrote:
> > > I'd like to see TOP_FRIENDS available as a filter as well as a sort
> > > option.
> > >
> > > Also, Where are we tracking these feature requests?
> > >
> > >
> > >
> >
> > >
> >
>

> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

Lou Moore

unread,
Apr 14, 2008, 3:38:14 PM4/14/08
to opensocial-an...@googlegroups.com
+1

Containers will have different algorithms for determining top friends but most do have the concept of top friends in some manner.

Graham Spencer

unread,
Apr 24, 2008, 7:27:50 PM4/24/08
to opensocial-an...@googlegroups.com
+1

--g

Cassie

unread,
Apr 25, 2008, 7:11:06 AM4/25/08
to opensocial-an...@googlegroups.com, Zhen Wang
Okay, we've got a +1 from Paul, Lou and Graham.
Zhen - was your question resolved? are you okay with this proposal now?

Thanks.
- Cassie

Sergio Marti

unread,
Apr 25, 2008, 12:58:27 PM4/25/08
to opensocial-an...@googlegroups.com, Zhen Wang
Does the spec describe what a container should do if the specified filter is not suppported?  Can the container use any filtering criteria it chooses in lieu of the specified filter or should it return an error saying unsupported filter?

Zhen Wang

unread,
Apr 25, 2008, 2:04:47 PM4/25/08
to Cassie, opensocial-an...@googlegroups.com
Yes, +1!

On Fri, Apr 25, 2008 at 4:11 AM, Cassie <do...@google.com> wrote:

Marco Ensing

unread,
Apr 25, 2008, 6:07:36 PM4/25/08
to OpenSocial and Gadgets Specification Discussion
Yes, +1


On Apr 25, 11:04 am, "Zhen Wang" <wa...@google.com> wrote:
> Yes, +1!
>
>
>
> On Fri, Apr 25, 2008 at 4:11 AM, Cassie <d...@google.com> wrote:
> > Okay, we've got a +1 from Paul, Lou and Graham.
> > Zhen - was your question resolved? are you okay with this proposal now?
>
> > Thanks.
> > - Cassie
>
> > On Fri, Apr 25, 2008 at 1:27 AM, Graham Spencer <g...@google.com> wrote:
>
> > > +1
>
> > > --g
>
> > > On Mon, Apr 14, 2008 at 12:38 PM, Lou Moore <lmo...@hi5.com> wrote:
>
> > > > +1
>
> > > > Containers will have different algorithms for determining top friends
> > but most do have the concept of top friends in some manner.
>
> > > > On 4/14/08 12:29 PM, "Paul Lindner" <lind...@inuus.com> wrote:
>
> > > > On Mon, Apr 14, 2008 at 12:01:05PM -0700, Zhen Wang wrote:
>
> > > > > How is the top_friends ranking function defined? And does this filter
> > > > > type imply that there's only one way to rank friends?
>
> > > > Different containers have different ways of delineating who is or is
> > > > not a top friend.  At hi5 the user decides this.
>
> > > > Other containers may choose a decent list with a variable cutoff.
>
> > > > > On Mon, Apr 14, 2008 at 4:58 AM, Cassie <d...@google.com> wrote:
>
> > > > > >  current proposal list:
> > > > > >  http://spreadsheets.google.com/pub?key=pigtmOB55Aw_YJHz040u0Kg
>
> > > > > >  spec change:
>
> > > > > >  opensocial.DataRequest.FilterType = {
> > > > > >  ...
> > > > > >   /**
> > > > > >    * Retrieves only the user's top friends.
> > > > > >    *
> > > > > >    * @member opensocial.DataRequest.FilterType
> > > > > >    */
> > > > > >   TOP_FRIENDS : 'topFriends',
> > > > > >  ...
> > > > > >  }
>
> > > > > >  votes/comments?
>
> > > > > >  - Cassie
>
> > > > > >  On Tue, Apr 8, 2008 at 12:17 AM, Paul Lindner <lind...@inuus.com>
> > wrote:
> > > > > >  > I'd like to see TOP_FRIENDS available as a filter as well as a
> > sort
> > > > > >  > option.
>
> > > > > >  > Also, Where are we tracking these feature requests?
>
> > > > > You received this message because you are subscribed to the Google
> > Groups "OpenSocial and Gadgets Specification Discussion" group.
> > > > > To post to this group, send email to
> > opensocial-an...@googlegroups.com
> > > > > To unsubscribe from this group, send email to
> > opensocial-and-gadg...@googlegroups.com
> > > > > For more options, visit this group at
> >http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > > > > -~----------~----~----~----~------~----~------~--~---
>
> > > > --
> > > > Paul Lindner        ||||| | | | |  |  |  |   |   |
> > > > lind...@inuus.com- Hide quoted text -
>
> - Show quoted text -

mnew...@myspace.com

unread,
Apr 25, 2008, 6:25:39 PM4/25/08
to OpenSocial and Gadgets Specification Discussion
+1

On Apr 25, 11:04 am, "Zhen Wang" <wa...@google.com> wrote:
> Yes, +1!
>
> On Fri, Apr 25, 2008 at 4:11 AM, Cassie <d...@google.com> wrote:
> > Okay, we've got a +1 from Paul, Lou and Graham.
> > Zhen - was your question resolved? are you okay with this proposal now?
>
> > Thanks.
> > - Cassie
>
> > On Fri, Apr 25, 2008 at 1:27 AM, Graham Spencer <g...@google.com> wrote:
>
> > > +1
>
> > > --g
>
> > > On Mon, Apr 14, 2008 at 12:38 PM, Lou Moore <lmo...@hi5.com> wrote:
>
> > > > +1
>
> > > > Containers will have different algorithms for determining top friends
> > but most do have the concept of top friends in some manner.
>
> > > > On 4/14/08 12:29 PM, "Paul Lindner" <lind...@inuus.com> wrote:
>
> > > > On Mon, Apr 14, 2008 at 12:01:05PM -0700, Zhen Wang wrote:
>
> > > > > How is the top_friends ranking function defined? And does this filter
> > > > > type imply that there's only one way to rank friends?
>
> > > > Different containers have different ways of delineating who is or is
> > > > not a top friend. At hi5 the user decides this.
>
> > > > Other containers may choose a decent list with a variable cutoff.
>
> > > > > On Mon, Apr 14, 2008 at 4:58 AM, Cassie <d...@google.com> wrote:
>
> > > > > > current proposal list:
> > > > > > http://spreadsheets.google.com/pub?key=pigtmOB55Aw_YJHz040u0Kg
>
> > > > > > spec change:
>
> > > > > > opensocial.DataRequest.FilterType = {
> > > > > > ...
> > > > > > /**
> > > > > > * Retrieves only the user's top friends.
> > > > > > *
> > > > > > * @member opensocial.DataRequest.FilterType
> > > > > > */
> > > > > > TOP_FRIENDS : 'topFriends',
> > > > > > ...
> > > > > > }
>
> > > > > > votes/comments?
>
> > > > > > - Cassie
>
> > > > > > On Tue, Apr 8, 2008 at 12:17 AM, Paul Lindner <lind...@inuus.com>
> > wrote:
> > > > > > > I'd like to see TOP_FRIENDS available as a filter as well as a
> > sort
> > > > > > > option.
>
> > > > > > > Also, Where are we tracking these feature requests?
>
> > > > > You received this message because you are subscribed to the Google
> > Groups "OpenSocial and Gadgets Specification Discussion" group.
> > > > > To post to this group, send email to
> > opensocial-an...@googlegroups.com
> > > > > To unsubscribe from this group, send email to
> > opensocial-and-gadg...@googlegroups.com
> > > > > For more options, visit this group at
> >http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > > > > -~----------~----~----~----~------~----~------~--~---
>
> > > > --
> > > > Paul Lindner ||||| | | | | | | | | |
> > > > lind...@inuus.com

Kevin Marks

unread,
Apr 25, 2008, 6:32:45 PM4/25/08
to opensocial-an...@googlegroups.com
My slight concern with this idea is that it is encouraging the applications to make assumptions about the container - I'd be wary of this becoming a precedent for defining complex group interactions between application and container. One of the key simplifications of OpenSocial is that the application asks for friends and the container gets to mediate the user's contextual understanding of friends for that application. I fully expect containers to allow users to choose different friend sets for different applications, and to define 'friends' in context-specific ways (for example, 'people nearby' or 'people who bought this product') that the contained application does not need to understand to be useful to the user.

Paul Lindner

unread,
Apr 25, 2008, 7:36:15 PM4/25/08
to opensocial-an...@googlegroups.com
In my opinion we should agree that TOP_FRIENDS is container specific
and could change from call-to-call depending on context.

Basically it's intentionally ambiguous.

On Fri, Apr 25, 2008 at 09:58:27AM -0700, Sergio Marti wrote:
> Does the spec describe what a container should do if the specified filter is
> not suppported? Can the container use any filtering criteria it chooses in
> lieu of the specified filter or should it return an error saying unsupported
> filter?
>
> On Fri, Apr 25, 2008 at 4:11 AM, Cassie <do...@google.com> wrote:
>
> > Okay, we've got a +1 from Paul, Lou and Graham.
> > Zhen - was your question resolved? are you okay with this proposal now?
> >
> > Thanks.
> > - Cassie
> >
> >
> >
> > On Fri, Apr 25, 2008 at 1:27 AM, Graham Spencer <g...@google.com> wrote:
> >
> >> +1
> >>
> >>
> >>

Paul

unread,
Apr 25, 2008, 8:42:40 PM4/25/08
to OpenSocial and Gadgets Specification Discussion
+1

I'm very supportive of the idea that OS Providers are free to define
top friends as they see fit. An OS Provider could even make the top
friends the first page of the typical friends call if they so chose.
It's extremely valuable for app developers to target a key group of
friends (especially for users that have an inordinate amount of
"friends").

~Paul

Cassie

unread,
Apr 27, 2008, 6:32:39 PM4/27/08
to opensocial-an...@googlegroups.com
sergio - if the filter is not supported then supportedField('filterType', 'topFriends') should return false. when an app developer makes a call with the topFriends filter when it isn't supported than the responseItem returned should have the error code set properly. as for the data set on the response item, that isn't defined by the spec. orkut could probably return null if you wanted to be strict or could just not filter the friends if you wanted to be more lenient.

everyone else - yes, the spec will fully state that the choice of "top friends" will be decided by each container individually. kevin - I hope this is what you meant by your comment but please respond if you disagree. I think that containers without top friends as a concept should be okay with this.

overall:
this spec change is approved unless there are any other objections.

thanks!

- cassie

Dan Peterson

unread,
Apr 28, 2008, 12:26:12 PM4/28/08
to Sergio Marti, opensocial-and-gadgets-spec, Zhen Wang
It seems like a common error is a better option that "pretending" to implement a given filter. Otherwise, if a filter we requested and a non-intuitive filter was applied, because the requested filter wasn't implemented, that could lead to some unfortunate results for the user.

Assuming we can do something sensible there, +1 to adding the filter.

-Dan

2008/4/25 Sergio Marti <sma...@google.com>:

Dan Peterson

unread,
Apr 28, 2008, 1:19:59 PM4/28/08
to Sergio Marti, opensocial-and-gadgets-spec, Zhen Wang
I was behind on my email --- Cassie's latest note seems to clarify the sitatuon, so let's just call this a +1.
 
-Dan
 
Reply all
Reply to author
Forward
0 new messages