requestSendMessage proposal

[Chad Russell]

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.

 

Any thoughts?

 

Thanks,

Chad Russell

crus...@myspace.com

[Graham Spencer]

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.

--g

[Amar Gandhi]

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-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Chad Russell
Sent: Friday, April 18, 2008 3:16 PM
To: opensocial-an...@googlegroups.com
Subject: requestSendMessage proposal

[fer...@gmail.com]

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.
>
> _____
>

> cruss...@myspace.com

[Cassie]

Okay, well the request for having sendMessage return the actual sender list is here with no consensus: (so please respond!)
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/04d654c18fc52c06#

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

[Reinoud Elhorst]

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.

[Cassie]

Chad (or someone else from myspace) - do you think you could respond to this thread with your thoughts?
Thanks!

- Cassie

[Chad Russell]

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

[Cassie]

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.

- Cassie