makeRequest POST parameters should be standardized

[Alex Epshteyn]

Currently some of the parameters passed to an app's server using a
signed makeRequest are not compatible between Orkut and MySpace.
These should be standardized across containers if they aren't so
already.

I just started this thread on the MySpace forum:

http://developer.myspace.com/Community/forums/p/1271/5525.aspx

which reads:

On MySpace these are called "opensocial_viewer_id" and
"opensocial_owner_id", whereas they should be called
"opensocial_viewerid" and "opensocial_ownerid" (without a second
underscore). This differs from Orkut's implementation of OpenSocial,
and poses a substantial hurdle to developers building cross-platform
apps.

[Kevin Brown]

Agreed -- I could have sworn this was already the case though. This has to be consistent across containers in order to ensure that developers don't have to modify their back end for every container.

--
~Kevin

[Chakradhar Nanga]

I completely agree that it makes sense to standardize the param naming conventions across containers. However, AFAIK, the OpenSocial spec does not explicitly address the issue of parameter naming for signed makeRequests - hence the different param names between Orkut and MySpace.

We (@ MySpace) have a number of app developers whose apps rely on our current naming convention and we do not want to break all of them by changing names at this stage. If the naming convention is indeed part of the spec, then we need to figure out a good solution to continue to support our existing app developers and be compatible with the spec at a later stage.

Thanks
Chak

[Paul Lindner]

Until we can agree on which is the standard why not send both versions
of the parameter :)

opensocial_owner_id=XX&opesocial_ownerid=XX

The at a later point we can deprecate one of the other.

On Fri, Mar 21, 2008 at 06:06:27PM -0700, Chakradhar Nanga wrote:
> I completely agree that it makes sense to standardize the param naming conventions across containers. However, AFAIK, the OpenSocial spec does not explicitly address the issue of parameter naming for signed makeRequests - hence the different param names between Orkut and MySpace.
>
> We (@ MySpace) have a number of app developers whose apps rely on our current naming convention and we do not want to break all of them by changing names at this stage. If the naming convention is indeed part of the spec, then we need to figure out a good solution to continue to support our existing app developers and be compatible with the spec at a later stage.
>
> Thanks
> Chak
>
>
>

> From: opensocial-an...@googlegroups.com on behalf of Kevin Brown
> Sent: Fri 3/21/2008 5:08 PM
> To: opensocial-an...@googlegroups.com
> Subject: Re: makeRequest POST parameters should be standardized
>
> Agreed -- I could have sworn this was already the case though. This has to
> be consistent across containers in order to ensure that developers don't
> have to modify their back end for every container.
>
> On Fri, Mar 21, 2008 at 4:34 PM, Alex Epshteyn <alexander...@gmail.com>
> wrote:
>
> >
> > Currently some of the parameters passed to an app's server using a
> > signed makeRequest are not compatible between Orkut and MySpace.
> > These should be standardized across containers if they aren't so
> > already.
> >
> > I just started this thread on the MySpace forum:
> >
> > http://developer.myspace.com/Community/forums/p/1271/5525.aspx
> >
> > which reads:
> >
> > On MySpace these are called "opensocial_viewer_id" and
> > "opensocial_owner_id", whereas they should be called
> > "opensocial_viewerid" and "opensocial_ownerid" (without a second
> > underscore). This differs from Orkut's implementation of OpenSocial,
> > and poses a substantial hurdle to developers building cross-platform
> > apps.
> >
> > >
> >
>
>

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

[Kevin Brown]

On Fri, Mar 21, 2008 at 6:06 PM, Chakradhar Nanga <cna...@myspace.com> wrote:

I completely agree that it makes sense to standardize the param naming conventions across containers. However, AFAIK, the OpenSocial spec does not explicitly address the issue of parameter naming for signed makeRequests - hence the different param names between Orkut and MySpace.

We (@ MySpace) have a number of app developers whose apps rely on our current naming convention and we do not want to break all of them by changing names at this stage. If the naming convention is indeed part of the spec, then we need to figure out a good solution to continue to support our existing app developers and be compatible with the spec at a later stage.

Unfortunately, I suspect whatever name we go with (and I don't really care either way, I hate underscores :)) is going to result in many developers having to make changes. Most of them are probably just using different code paths for myspace vs. orkut today, and if one container or the other changes, they'll have to change in any case. It's probably slightly easier to get Orkut to change at this point since they haven't launched to all users quite yet.

--
~Kevin

[Chakradhar Nanga]

Hi Paul,

That's my current thinking exactly

Thanks
Chak

[Chakradhar Nanga]

>> It's probably slightly easier to get Orkut to change at this point since they haven't launched to all users quite yet

That works for us too, Kevin :-)

[Kevin Brown]

Sounds good to me as well.

--
~Kevin

[Kevin Brown]

On Fri, Mar 21, 2008 at 6:18 PM, Kevin Brown <et...@google.com> wrote:

Sounds good to me as well.

Scratch that, I'm not thinking -- this would just break the signatures for both Myspace and Orkut.

I'd rather minimize the pain on developers, not maximize it! :)

--
~Kevin

[Louis Ryan]

Im fine with changing for Orkut/Google too as we can run the change through our sandbox deployment before pushing to production.

@Chak Does MySpace have a beta mechanism where you can push breaking changes for app developers to test before rolling them out more broadly?

[Cassie]

Would the following change to the spec for 0.8 work?

  /**
     * Fetches content from the provided URL and feeds that content into the
     * callback function. If the request is SIGNED will pass the following
     * parameters along to the requested Url:
     *   - opensocial_viewer_id    The id of the current viewer, will match the
     *       getId() value on the viewer person object
     *   - opensocial_owner_id    The id of the current owner, will match the
     *       getId() value on the owner person object
     *
     ...
     *
     * @member gadgets.io
     */
    makeRequest : function (url, callback, opt_params) {


Did I miss anything or would anybody like to choose different parameter names?
Thanks.

- Cassie

[Alex Epshteyn]

That works! As long as it's documented :)

Thanks,
Alex

[Chak Nanga]

+1 for the proposal below (with the param names opensocial_viewer_id, opensocial_owner_id )

Thanks
Chak

On 3/31/08 8:03 AM, "Cassie" <do...@google.com> wrote:

Would the following change to the spec for 0.8 work?

  /**
     * Fetches content from the provided URL and feeds that content into the
     * callback function. If the request is SIGNED will pass the following
     * parameters along to the requested Url:
     *   - opensocial_viewer_id    The id of the current viewer, will match the
     *       getId() value on the viewer person object
     *   - opensocial_owner_id    The id of the current owner, will match the
     *       getId() value on the owner person object
    *
     ...
     *

     * @member gadgets.io <http://gadgets.io>

[Brian Eaton]

On Mon, Mar 31, 2008 at 8:03 AM, Cassie <do...@google.com> wrote:
> Did I miss anything or would anybody like to choose different parameter
> names?

opensocial_app_id should be the URL of the gadget.

xoauth_signature_publickey should be an identifier for the public key.
There are some proposals out there on how to use this for key
rotation, but as far as I know no one is close to implementing them.
We could either push to figure this out, or else postpone adding it to
the spec.

[John Panzer]

+1

On Mon, Mar 31, 2008 at 8:03 AM, Cassie <do...@google.com> wrote:

[Maxwell Newbould]

+1

[Cassie]

I believe this thread has enough positive +1s and is thus good to go for 0.8

- Cassie