Separation of Gadgets and OpenSocial (Option 2)

[Lane LiaBraaten, 2009-11-02 23:03:07]

In general, I'm not sure all of these changes are predicated on the social vs.
plain ol' gadgets distinction.  For example, information about the owner and
viewer may be useful even in a non-social environment.

http://codereview.appspot.com/144071/diff/1/2
File draft/Gadgets-API-Specification.xml (left):

http://codereview.appspot.com/144071/diff/1/2#oldcode574
Line 574: <t>sign_owner: gadgets.io.RequestParameters.SIGN_OWNER (default
'true')</t>
I'm not convinced it makes sense to remove these.  Regardless of being "social",
a container make know (and care) about the identity viewing a gadget and the
identity that "owns" the page a gadget is being rendered on

http://codereview.appspot.com/144071/diff/1/2#oldcode841
Line 841: <t hangText="opensocial_app_url">Required. The URL of the application
Some identifier for the app must be included in the signature.  Otherwise, if
the Foo gadget sent a request to the Bar gadget's backend, there would be no way
for Bar's backend to tell if the request came from the Foo gadget or the Bar
gadget (n.b. in the case of public key signing). 

Put another way, oauth signatures let the server verify that request came from
the container, but don't account for the fact that multiple app are running on
thta container.

http://codereview.appspot.com/144071/diff/1/2#oldcode845
Line 845: <t hangText="opensocial_instance_id">Optional. An opaque identifier
I don't think we can remove this either. A container allowing multiple instances
of a gadget is different for it being "social"

http://codereview.appspot.com/144071/diff/1/2
File draft/Gadgets-API-Specification.xml (right):

http://codereview.appspot.com/144071/diff/1/2#newcode71
Line 71: capabilities like a rich set of social APIs.</t>
"Applications like OpenSocial" confuses me.  I think we can do without this last
sentence.

http://codereview.appspot.com/144071/diff/1/2#newcode838
Line 838: <t>Adding application specific parameters to the request query
Change the colon ":" at the end to a period "."

http://codereview.appspot.com/144071/diff/1/2#newcode864
Line 864:
https://[container-hostname]/[application-name]/certificates/xoauth_public_keyvalue
I think we can drop the [application-name].  i.e.
https://[container-hostname]/certificates/xoauth_public_keyvalue

http://codereview.appspot.com/144071/diff/1/3
File draft/OpenSocial-Specification.xml (right):

http://codereview.appspot.com/144071/diff/1/3#newcode512
Line 512: <section title="Public Key Location">
I think we can just use 
https://[container-hostname]/certificates/xoauth_public_keyvalue and not include
this section in the opensocial spec.

http://codereview.appspot.com/144071/diff/1/3#newcode517
Line 517: <section title="gadgets.views.ViewType"
I think these should remain in the gadgets spec.  Views are related to how a
gadget is rendered, not whether it is social or not.

Also, this spec does not require all containers to support all views (hence the
getSupportedViews method).

[Jon Weygandt, 2009-11-05 00:49:52]

http://codereview.appspot.com/144071/diff/1/2
File draft/Gadgets-API-Specification.xml (left):

http://codereview.appspot.com/144071/diff/1/2#oldcode574
Line 574: <t>sign_owner: gadgets.io.RequestParameters.SIGN_OWNER (default
'true')</t>
See the comment in the OpenSocial specification on the Views. We can keep these
here the same way.

http://codereview.appspot.com/144071/diff/1/2#oldcode841
Line 841: <t hangText="opensocial_app_url">Required. The URL of the application
agreed

http://codereview.appspot.com/144071/diff/1/2#oldcode845
Line 845: <t hangText="opensocial_instance_id">Optional. An opaque identifier
agreed. See notes in the OpenSocial specification on views. 
I think we keep this whole section. We grandfather in the names (e.g. keep
"opensocial" prefix). owner_id is optional for gadgets, but in the OS spec
described as required.

For gadgets - we can describe the owner is the user who went through the process
of subscribing to the gadget or placing the gadget on their page. The viewer
would be the current logged in user or the reserved word "guest" for someone not
logged in.

For OS we would keep the more precise wordings.

BTW - We have gadgets where the owner is either irrelevant or implicit, and at
times the viewer is more important.

http://codereview.appspot.com/144071/diff/1/2
File draft/Gadgets-API-Specification.xml (right):

http://codereview.appspot.com/144071/diff/1/2#newcode71
Line 71: capabilities like a rich set of social APIs.</t>
OK

http://codereview.appspot.com/144071/diff/1/2#newcode864
Line 864:
https://[container-hostname]/[application-name]/certificates/xoauth_public_keyvalue
See my notes on the OpenSocial spec, in a similar section.

http://codereview.appspot.com/144071/diff/1/3
File draft/OpenSocial-Specification.xml (right):

http://codereview.appspot.com/144071/diff/1/3#newcode512
Line 512: <section title="Public Key Location">
I like the absence of <application>, just worried changing it might look like
"breaking" backwards compatibility. Of course the value is only "recommended".

It could be worded like, "The recommended name is <the one w/o application>.
Some containers may wish to support <the one with application> as well for
compatibility with versions of the specification prior to 1.0.

http://codereview.appspot.com/144071/diff/1/3#newcode517
Line 517: <section title="gadgets.views.ViewType"
I can put them back along with the words:
"The following are some values that may be supported by the application. Should
the application support them, they must be implemented as follows."
This will provide some common language between different applications.