Hey all, here at MySpace we've come across an issue with opensocial.requestSendMessage, so I'd like to propose a change to it for the 0.8 spec.
The spec calls for "recipients" to be passed in, which is essentially an idSpec. When we display the popup dialog we don't do any server action until the user hits the "send" button. So what we actually want is an opensocial.Person object passed up, which, according to spec, must contain the ID, image and URL. That's enough for us to populate the UI without hitting the server for that information.
This seems a natural way of doing things, I imagine a common use-case of: fetching the viewer's friends when the app loads, displaying a "friend picker", attaching each friend to the corresponding opensocial.Person object, then when clicked initiate a requestSendMessage and pass in the Person. If you have the ID of a friend, then I think you must have the Person object, correct? Is there another way for an app to know my friend's IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person objects, or possibly persisting the social graph?
Currently we are forced to have requestSendMessage go fetch the person object given the ID, and in the callback show the popup UI. This is pretty ugly, especially considering that to get that ID we have already probably made a newFetchPeopleRequest.
So my proposal is to allow both IDs and Person objects to be passed up into requestSendMessage, as I'm sure I just missed the use case where an app has the ID but not the Person, but it'd really work well for us to allow both.
Can you cache the id->person mapping when person objects are delivered to the application? That way you could retrieve the person object without a server round trip. If the id isn't in the cache, then a round trip is required anyway, either by library code or by the app code.
On Fri, Apr 18, 2008 at 3:15 PM, Chad Russell <cruss...@myspace.com> wrote: > Hey all, here at MySpace we've come across an issue with > opensocial.requestSendMessage, so I'd like to propose a change to it for the > 0.8 spec.
> The spec calls for "recipients" to be passed in, which is essentially an > idSpec. When we display the popup dialog we don't do any server action > until the user hits the "send" button. So what we actually want is an > opensocial.Person object passed up, which, according to spec, must contain > the ID, image and URL. That's enough for us to populate the UI without > hitting the server for that information.
> This seems a natural way of doing things, I imagine a common use-case of: > fetching the viewer's friends when the app loads, displaying a "friend > picker", attaching each friend to the corresponding opensocial.Person > object, then when clicked initiate a requestSendMessage and pass in the > Person. If you have the ID of a friend, then I think you must have the > Person object, correct? Is there another way for an app to know my friend's > IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person > objects, or possibly persisting the social graph?
> Currently we are forced to have requestSendMessage go fetch the person > object given the ID, and in the callback show the popup UI. This is pretty > ugly, especially considering that to get that ID we have already probably > made a newFetchPeopleRequest.
> So my proposal is to allow both IDs and Person objects to be passed up into > requestSendMessage, as I'm sure I just missed the use case where an app has > the ID but not the Person, but it'd really work well for us to allow both.
orkut is about to implement user-to-user messaging and we have a related ask.
for abuse reasons, orkut will allow the app to pass in atmost one person. users can select ppl using an orkut friend picker dialog that will show upon requestSendMessage. the application should get back the list of friends that the user selected. so, for an events application, the application can see all the friends invited to the party.
so the requested change is for the callback to return the list of users that the message will be sent to.
_____
From: opensocial-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Chad Russell Sent: Friday, April 18, 2008 3:16 PM To: opensocial-and-gadgets-spec@googlegroups.com Subject: requestSendMessage proposal
Hey all, here at MySpace we've come across an issue with opensocial.requestSendMessage, so I'd like to propose a change to it for the 0.8 spec.
The spec calls for "recipients" to be passed in, which is essentially an idSpec. When we display the popup dialog we don't do any server action until the user hits the "send" button. So what we actually want is an opensocial.Person object passed up, which, according to spec, must contain the ID, image and URL. That's enough for us to populate the UI without hitting the server for that information.
This seems a natural way of doing things, I imagine a common use-case of: fetching the viewer's friends when the app loads, displaying a "friend picker", attaching each friend to the corresponding opensocial.Person object, then when clicked initiate a requestSendMessage and pass in the Person. If you have the ID of a friend, then I think you must have the Person object, correct? Is there another way for an app to know my friend's IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person objects, or possibly persisting the social graph?
Currently we are forced to have requestSendMessage go fetch the person object given the ID, and in the callback show the popup UI. This is pretty ugly, especially considering that to get that ID we have already probably made a newFetchPeopleRequest.
So my proposal is to allow both IDs and Person objects to be passed up into requestSendMessage, as I'm sure I just missed the use case where an app has the ID but not the Person, but it'd really work well for us to allow both.
> orkut is about to implement user-to-user messaging and we have a related
> ask.
> for abuse reasons, orkut will allow the app to pass in atmost one person.
> users can select ppl using an orkut friend picker dialog that will show upon
> requestSendMessage. the application should get back the list of friends
> that the user selected. so, for an events application, the application can
> see all the friends invited to the party.
> so the requested change is for the callback to return the list of users that
> the message will be sent to.
> _____
> From: opensocial-and-gadgets-spec@googlegroups.com
> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Chad
> Russell
> Sent: Friday, April 18, 2008 3:16 PM
> To: opensocial-and-gadgets-spec@googlegroups.com
> Subject: requestSendMessage proposal
> Hey all, here at MySpace we've come across an issue with
> opensocial.requestSendMessage, so I'd like to propose a change to it for the
> 0.8 spec.
> The spec calls for "recipients" to be passed in, which is essentially an
> idSpec. When we display the popup dialog we don't do any server action
> until the user hits the "send" button. So what we actually want is an
> opensocial.Person object passed up, which, according to spec, must contain
> the ID, image and URL. That's enough for us to populate the UI without
> hitting the server for that information.
> This seems a natural way of doing things, I imagine a common use-case of:
> fetching the viewer's friends when the app loads, displaying a "friend
> picker", attaching each friend to the corresponding opensocial.Person
> object, then when clicked initiate a requestSendMessage and pass in the
> Person. If you have the ID of a friend, then I think you must have the
> Person object, correct? Is there another way for an app to know my friend's
> IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person
> objects, or possibly persisting the social graph?
> Currently we are forced to have requestSendMessage go fetch the person
> object given the ID, and in the callback show the popup UI. This is pretty
> ugly, especially considering that to get that ID we have already probably
> made a newFetchPeopleRequest.
> So my proposal is to allow both IDs and Person objects to be passed up into
> requestSendMessage, as I'm sure I just missed the use case where an app has
> the ID but not the Person, but it'd really work well for us to allow both.
The id to person cache is implementation specific, so myspace can decide on whether they want themselves.
As for changing from idSpec->person. Myspace, if you still want it, the spec change would look like this: (I have it relying on the IdSpec object proposal just for simplicity. I'll take it out if that one doesn't go through)
* @param {Array<opensocial.Person> || opensocial.IdSpec} recipients An array * of people or an idSpec indicating who to send the message to. opensocial.requestSendMessage = function(recipients, message, opt_callback) {};
Thanks. - Cassie
On Sat, Apr 19, 2008 at 4:05 AM, fern...@gmail.com <fern...@gmail.com> wrote:
> +3 for response of sendMessage to return the actual sender list. > +2 for allowing to pass in Person objects > +1 for having an ID->PersonObject cache
> On Apr 18, 3:26 pm, "Amar Gandhi" <am...@google.com> wrote: > > orkut is about to implement user-to-user messaging and we have a related > > ask.
> > for abuse reasons, orkut will allow the app to pass in atmost one person. > > users can select ppl using an orkut friend picker dialog that will show > upon > > requestSendMessage. the application should get back the list of friends > > that the user selected. so, for an events application, the application > can > > see all the friends invited to the party.
> > so the requested change is for the callback to return the list of users > that > > the message will be sent to.
> > _____
> > From: opensocial-and-gadgets-spec@googlegroups.com > > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Chad > > Russell > > Sent: Friday, April 18, 2008 3:16 PM > > To: opensocial-and-gadgets-spec@googlegroups.com > > Subject: requestSendMessage proposal
> > Hey all, here at MySpace we've come across an issue with > > opensocial.requestSendMessage, so I'd like to propose a change to it for > the > > 0.8 spec.
> > The spec calls for "recipients" to be passed in, which is essentially an > > idSpec. When we display the popup dialog we don't do any server action > > until the user hits the "send" button. So what we actually want is an > > opensocial.Person object passed up, which, according to spec, must > contain > > the ID, image and URL. That's enough for us to populate the UI without > > hitting the server for that information.
> > This seems a natural way of doing things, I imagine a common use-case of: > > fetching the viewer's friends when the app loads, displaying a "friend > > picker", attaching each friend to the corresponding opensocial.Person > > object, then when clicked initiate a requestSendMessage and pass in the > > Person. If you have the ID of a friend, then I think you must have the > > Person object, correct? Is there another way for an app to know my > friend's > > IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person > > objects, or possibly persisting the social graph?
> > Currently we are forced to have requestSendMessage go fetch the person > > object given the ID, and in the callback show the popup UI. This is > pretty > > ugly, especially considering that to get that ID we have already probably > > made a newFetchPeopleRequest.
> > So my proposal is to allow both IDs and Person objects to be passed up > into > > requestSendMessage, as I'm sure I just missed the use case where an app > has > > the ID but not the Person, but it'd really work well for us to allow > both.
On allowing person array on the requestSendMessage: It doesn't seem to be enough on the usecase you're describing. What guarantees do you have that the application hasn't tampered with the person object. It might supply you with a person object with the id of your old girlfriend, and the name of your current girlfriend. So the user that has to agree to the message being sent in the popup has no secure way of knowing who the recipients are.
I guess this could be solved again by a signature, or checking the supplied names against the names in the database after the message has been sent, but this seems to me to be as much trouble as caching the id-->name as Graham suggested.
On Sun, Apr 20, 2008 at 7:27 PM, Cassie <d...@google.com> wrote: > Okay, well the request for having sendMessage return the actual sender > list is here with no consensus: (so please respond!)
> The id to person cache is implementation specific, so myspace can decide > on whether they want themselves.
> As for changing from idSpec->person. Myspace, if you still want it, the > spec change would look like this: > (I have it relying on the IdSpec object proposal just for simplicity. I'll > take it out if that one doesn't go through)
> * @param {Array<opensocial.Person> || opensocial.IdSpec} recipients An > array > * of people or an idSpec indicating who to send the message to. > opensocial.requestSendMessage = function(recipients, message, > opt_callback) {};
> Thanks. > - Cassie
> On Sat, Apr 19, 2008 at 4:05 AM, fern...@gmail.com <fern...@gmail.com> > wrote:
> > good ideas! :)
> > +3 for response of sendMessage to return the actual sender list. > > +2 for allowing to pass in Person objects > > +1 for having an ID->PersonObject cache
> > On Apr 18, 3:26 pm, "Amar Gandhi" <am...@google.com> wrote: > > > orkut is about to implement user-to-user messaging and we have a > > related > > > ask.
> > > for abuse reasons, orkut will allow the app to pass in atmost one > > person. > > > users can select ppl using an orkut friend picker dialog that will > > show upon > > > requestSendMessage. the application should get back the list of > > friends > > > that the user selected. so, for an events application, the > > application can > > > see all the friends invited to the party.
> > > so the requested change is for the callback to return the list of > > users that > > > the message will be sent to.
> > > _____
> > > From: opensocial-and-gadgets-spec@googlegroups.com > > > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of > > Chad > > > Russell > > > Sent: Friday, April 18, 2008 3:16 PM > > > To: opensocial-and-gadgets-spec@googlegroups.com > > > Subject: requestSendMessage proposal
> > > Hey all, here at MySpace we've come across an issue with > > > opensocial.requestSendMessage, so I'd like to propose a change to it > > for the > > > 0.8 spec.
> > > The spec calls for "recipients" to be passed in, which is essentially > > an > > > idSpec. When we display the popup dialog we don't do any server > > action > > > until the user hits the "send" button. So what we actually want is an > > > opensocial.Person object passed up, which, according to spec, must > > contain > > > the ID, image and URL. That's enough for us to populate the UI > > without > > > hitting the server for that information.
> > > This seems a natural way of doing things, I imagine a common use-case > > of: > > > fetching the viewer's friends when the app loads, displaying a "friend > > > picker", attaching each friend to the corresponding opensocial.Person > > > object, then when clicked initiate a requestSendMessage and pass in > > the > > > Person. If you have the ID of a friend, then I think you must have > > the > > > Person object, correct? Is there another way for an app to know my > > friend's > > > IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person > > > objects, or possibly persisting the social graph?
> > > Currently we are forced to have requestSendMessage go fetch the person > > > object given the ID, and in the callback show the popup UI. This is > > pretty > > > ugly, especially considering that to get that ID we have already > > probably > > > made a newFetchPeopleRequest.
> > > So my proposal is to allow both IDs and Person objects to be passed up > > into > > > requestSendMessage, as I'm sure I just missed the use case where an > > app has > > > the ID but not the Person, but it'd really work well for us to allow > > both.
On Mon, Apr 21, 2008 at 1:58 PM, Reinoud Elhorst <rein...@hyves.nl> wrote: > On allowing person array on the requestSendMessage: It doesn't seem to be > enough on the usecase you're describing. What guarantees do you have that > the application hasn't tampered with the person object. It might supply you > with a person object with the id of your old girlfriend, and the name of > your current girlfriend. So the user that has to agree to the message being > sent in the popup has no secure way of knowing who the recipients are.
> I guess this could be solved again by a signature, or checking the supplied > names against the names in the database after the message has been sent, but > this seems to me to be as much trouble as caching the id-->name as Graham > suggested.
> On Sun, Apr 20, 2008 at 7:27 PM, Cassie <d...@google.com> wrote:
>> Okay, well the request for having sendMessage return the actual sender >> list is here with no consensus: (so please respond!)
>> The id to person cache is implementation specific, so myspace can decide >> on whether they want themselves.
>> As for changing from idSpec->person. Myspace, if you still want it, the >> spec change would look like this: >> (I have it relying on the IdSpec object proposal just for simplicity. I'll >> take it out if that one doesn't go through)
>> * @param {Array<opensocial.Person> || opensocial.IdSpec} recipients An >> array >> * of people or an idSpec indicating who to send the message to. >> opensocial.requestSendMessage = function(recipients, message, >> opt_callback) {};
>> Thanks. >> - Cassie
>> On Sat, Apr 19, 2008 at 4:05 AM, fern...@gmail.com <fern...@gmail.com> >> wrote:
>>> good ideas! :)
>>> +3 for response of sendMessage to return the actual sender list. >>> +2 for allowing to pass in Person objects >>> +1 for having an ID->PersonObject cache
>>> On Apr 18, 3:26 pm, "Amar Gandhi" <am...@google.com> wrote: >>> > orkut is about to implement user-to-user messaging and we have a >>> related >>> > ask.
>>> > for abuse reasons, orkut will allow the app to pass in atmost one >>> person. >>> > users can select ppl using an orkut friend picker dialog that will show >>> upon >>> > requestSendMessage. the application should get back the list of >>> friends >>> > that the user selected. so, for an events application, the application >>> can >>> > see all the friends invited to the party.
>>> > so the requested change is for the callback to return the list of users >>> that >>> > the message will be sent to.
>>> > _____
>>> > From: opensocial-and-gadgets-spec@googlegroups.com >>> > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of >>> Chad >>> > Russell >>> > Sent: Friday, April 18, 2008 3:16 PM >>> > To: opensocial-and-gadgets-spec@googlegroups.com >>> > Subject: requestSendMessage proposal
>>> > Hey all, here at MySpace we've come across an issue with >>> > opensocial.requestSendMessage, so I'd like to propose a change to it >>> for the >>> > 0.8 spec.
>>> > The spec calls for "recipients" to be passed in, which is essentially >>> an >>> > idSpec. When we display the popup dialog we don't do any server action >>> > until the user hits the "send" button. So what we actually want is an >>> > opensocial.Person object passed up, which, according to spec, must >>> contain >>> > the ID, image and URL. That's enough for us to populate the UI without >>> > hitting the server for that information.
>>> > This seems a natural way of doing things, I imagine a common use-case >>> of: >>> > fetching the viewer's friends when the app loads, displaying a "friend >>> > picker", attaching each friend to the corresponding opensocial.Person >>> > object, then when clicked initiate a requestSendMessage and pass in the >>> > Person. If you have the ID of a friend, then I think you must have the >>> > Person object, correct? Is there another way for an app to know my >>> friend's >>> > IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person >>> > objects, or possibly persisting the social graph?
>>> > Currently we are forced to have requestSendMessage go fetch the person >>> > object given the ID, and in the callback show the popup UI. This is >>> pretty >>> > ugly, especially considering that to get that ID we have already >>> probably >>> > made a newFetchPeopleRequest.
>>> > So my proposal is to allow both IDs and Person objects to be passed up >>> into >>> > requestSendMessage, as I'm sure I just missed the use case where an app >>> has >>> > the ID but not the Person, but it'd really work well for us to allow >>> both.
Sure... we've been following the philosophy that no one will want to use the "destroy my relationship" app described below, and they'll uninstall it, and it will never be successful. We exposed this functionality on MySpace weeks ago and have had no problems.
Chad
From: Cassie [mailto:d...@google.com] Sent: Monday, April 28, 2008 4:21 AM To: opensocial-and-gadgets-spec@googlegroups.com; Chad Russell Subject: Re: requestSendMessage proposal
Chad (or someone else from myspace) - do you think you could respond to this thread with your thoughts? Thanks!
- Cassie
On Mon, Apr 21, 2008 at 1:58 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
On allowing person array on the requestSendMessage: It doesn't seem to be enough on the usecase you're describing. What guarantees do you have that the application hasn't tampered with the person object. It might supply you with a person object with the id of your old girlfriend, and the name of your current girlfriend. So the user that has to agree to the message being sent in the popup has no secure way of knowing who the recipients are.
I guess this could be solved again by a signature, or checking the supplied names against the names in the database after the message has been sent, but this seems to me to be as much trouble as caching the id-->name as Graham suggested.
On Sun, Apr 20, 2008 at 7:27 PM, Cassie <d...@google.com> wrote:
The id to person cache is implementation specific, so myspace can decide on whether they want themselves.
As for changing from idSpec->person. Myspace, if you still want it, the spec change would look like this: (I have it relying on the IdSpec object proposal just for simplicity. I'll take it out if that one doesn't go through)
* @param {Array<opensocial.Person> || opensocial.IdSpec} recipients An array * of people or an idSpec indicating who to send the message to. opensocial.requestSendMessage = function(recipients, message, opt_callback) {};
Thanks. - Cassie
On Sat, Apr 19, 2008 at 4:05 AM, fern...@gmail.com <fern...@gmail.com> wrote:
good ideas! :)
+3 for response of sendMessage to return the actual sender list. +2 for allowing to pass in Person objects +1 for having an ID->PersonObject cache
On Apr 18, 3:26 pm, "Amar Gandhi" <am...@google.com> wrote:
> orkut is about to implement user-to-user messaging and we have a related > ask.
> for abuse reasons, orkut will allow the app to pass in atmost one person. > users can select ppl using an orkut friend picker dialog that will show upon > requestSendMessage. the application should get back the list of friends > that the user selected. so, for an events application, the application can > see all the friends invited to the party.
> so the requested change is for the callback to return the list of users that > the message will be sent to.
> _____
> From: opensocial-and-gadgets-spec@googlegroups.com > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Chad > Russell > Sent: Friday, April 18, 2008 3:16 PM > To: opensocial-and-gadgets-spec@googlegroups.com > Subject: requestSendMessage proposal
> Hey all, here at MySpace we've come across an issue with > opensocial.requestSendMessage, so I'd like to propose a change to it for the > 0.8 spec.
> The spec calls for "recipients" to be passed in, which is essentially an > idSpec. When we display the popup dialog we don't do any server action > until the user hits the "send" button. So what we actually want is an > opensocial.Person object passed up, which, according to spec, must contain > the ID, image and URL. That's enough for us to populate the UI without > hitting the server for that information.
> This seems a natural way of doing things, I imagine a common use-case of: > fetching the viewer's friends when the app loads, displaying a "friend > picker", attaching each friend to the corresponding opensocial.Person > object, then when clicked initiate a requestSendMessage and pass in the > Person. If you have the ID of a friend, then I think you must have the > Person object, correct? Is there another way for an app to know my friend's > IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person > objects, or possibly persisting the social graph?
> Currently we are forced to have requestSendMessage go fetch the person > object given the ID, and in the callback show the popup UI. This is pretty > ugly, especially considering that to get that ID we have already probably > made a newFetchPeopleRequest.
> So my proposal is to allow both IDs and Person objects to be passed up into > requestSendMessage, as I'm sure I just missed the use case where an app has > the ID but not the Person, but it'd really work well for us to allow both.
This thread does not seem to be getting enough positive consensus for 0.8 so I would like to close this thread and continue the discussion for 0.9 Thanks.
On Mon, Apr 28, 2008 at 7:48 PM, Chad Russell <cruss...@myspace.com> wrote: > Sure… we've been following the philosophy that no one will want to use > the "destroy my relationship" app described below, and they'll uninstall it, > and it will never be successful. We exposed this functionality on MySpace > weeks ago and have had no problems.
> Chad
> *From:* Cassie [mailto:d...@google.com] > *Sent:* Monday, April 28, 2008 4:21 AM > *To:* opensocial-and-gadgets-spec@googlegroups.com; Chad Russell > *Subject:* Re: requestSendMessage proposal
> Chad (or someone else from myspace) - do you think you could respond to > this thread with your thoughts? > Thanks!
> - Cassie
> On Mon, Apr 21, 2008 at 1:58 PM, Reinoud Elhorst <rein...@hyves.nl> > wrote:
> On allowing person array on the requestSendMessage: It doesn't seem to be > enough on the usecase you're describing. What guarantees do you have that > the application hasn't tampered with the person object. It might supply you > with a person object with the id of your old girlfriend, and the name of > your current girlfriend. So the user that has to agree to the message being > sent in the popup has no secure way of knowing who the recipients are.
> I guess this could be solved again by a signature, or checking the supplied > names against the names in the database after the message has been sent, but > this seems to me to be as much trouble as caching the id-->name as Graham > suggested.
> On Sun, Apr 20, 2008 at 7:27 PM, Cassie <d...@google.com> wrote:
> Okay, well the request for having sendMessage return the actual sender list > is here with no consensus: (so please respond!)
> The id to person cache is implementation specific, so myspace can decide on > whether they want themselves.
> As for changing from idSpec->person. Myspace, if you still want it, the > spec change would look like this: > (I have it relying on the IdSpec object proposal just for simplicity. I'll > take it out if that one doesn't go through)
> * @param {Array<opensocial.Person> || opensocial.IdSpec} recipients An > array > * of people or an idSpec indicating who to send the message to. > opensocial.requestSendMessage = function(recipients, message, opt_callback) > {};
> Thanks. > - Cassie
> On Sat, Apr 19, 2008 at 4:05 AM, fern...@gmail.com <fern...@gmail.com> > wrote:
> good ideas! :)
> +3 for response of sendMessage to return the actual sender list. > +2 for allowing to pass in Person objects > +1 for having an ID->PersonObject cache
> On Apr 18, 3:26 pm, "Amar Gandhi" <am...@google.com> wrote: > > orkut is about to implement user-to-user messaging and we have a related > > ask.
> > for abuse reasons, orkut will allow the app to pass in atmost one person. > > users can select ppl using an orkut friend picker dialog that will show > upon > > requestSendMessage. the application should get back the list of friends > > that the user selected. so, for an events application, the application > can > > see all the friends invited to the party.
> > so the requested change is for the callback to return the list of users > that > > the message will be sent to.
> > _____
> > From: opensocial-and-gadgets-spec@googlegroups.com > > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Chad > > Russell > > Sent: Friday, April 18, 2008 3:16 PM > > To: opensocial-and-gadgets-spec@googlegroups.com > > Subject: requestSendMessage proposal
> > Hey all, here at MySpace we've come across an issue with > > opensocial.requestSendMessage, so I'd like to propose a change to it for > the > > 0.8 spec.
> > The spec calls for "recipients" to be passed in, which is essentially an > > idSpec. When we display the popup dialog we don't do any server action > > until the user hits the "send" button. So what we actually want is an > > opensocial.Person object passed up, which, according to spec, must > contain > > the ID, image and URL. That's enough for us to populate the UI without > > hitting the server for that information.
> > This seems a natural way of doing things, I imagine a common use-case of: > > fetching the viewer's friends when the app loads, displaying a "friend > > picker", attaching each friend to the corresponding opensocial.Person > > object, then when clicked initiate a requestSendMessage and pass in the > > Person. If you have the ID of a friend, then I think you must have the > > Person object, correct? Is there another way for an app to know my > friend's > > IDs beyond a newFetchPeopleRequest -- which returns opensocial.Person > > objects, or possibly persisting the social graph?
> > Currently we are forced to have requestSendMessage go fetch the person > > object given the ID, and in the callback show the popup UI. This is > pretty > > ugly, especially considering that to get that ID we have already probably > > made a newFetchPeopleRequest.
> > So my proposal is to allow both IDs and Person objects to be passed up > into > > requestSendMessage, as I'm sure I just missed the use case where an app > has > > the ID but not the Person, but it'd really work well for us to allow > both.
|
