OpenSocial v0.7 Released!

[Lane LiaBraaten]

Hi Everyone,

Check out the new features of v0.7 at code.google.com/apis/opensocial/
docs/releasenotes.html. In addition to the updates to the OpenSocial
API reference [1], be sure to check out the new Gadgets Specification
[2] and API Reference [3]. The folks contributing to the Shindig
project are working hard to implement this new version so you'll have
a place to try it out.

Cheers,
Lane

[1] http://code.google.com/apis/opensocial/docs/0.7/reference/
[2] http://code.google.com/apis/gadgets/docs/spec.html
[3] http://code.google.com/apis/gadgets/docs/reference/

[the1geek]

Since OpenSocial API is currently in flux, it'd be nice to also
include the notation - supported "since v0.6" after each Interface/
Field/Method header in the reference documentation. That would
facilitate our version control management a bit.

BTW i like the change to views from surfaces in the new Gadget specs.
It's more legible!

~newton

[wessel...@googlemail.com]

Hello,

As i saw in the release notes gadget api feature libs are taken into
gadgets* namespace, but in the reference of that its mentioned that
its not yet released.
So my question is if i should use for e.g. tabs lib the gadgets*
namespace because tabs are not working for me in orkut sandbox using
_IG_TAB...

marc

[makar...@gmail.com]

Hello,

Does anyone know whether orkut sandbox has been updated to support v
0.7 ?????

Cheers,
Makarand

[rush]

Hi,

Same question here.
Bcoz with opensocial-0.7, no application is running. It gives error
"Bad, bad server. No donut for you."

Thanks
Rush

On Jan 28, 11:30 am, "makaran...@gmail.com" <makaran...@gmail.com>
wrote:

> > [3]http://code.google.com/apis/gadgets/docs/reference/- Hide quoted text -
>
> - Show quoted text -

[Dan Peterson]

Hi there,

orkut's sandbox has not yet been updated to version 0.7 since the API was only recently defined. Orkut is running 0.6.

-Dan

[rush]

Hi Dan,

Thanks for ur reply :)

> > > > [3]http://code.google.com/apis/gadgets/docs/reference/-Hide quoted
> > text -
>
> > > - Show quoted text -- Hide quoted text -

[Reinoud Elhorst]

First of all, congrats on getting out the 0.7 spec!

I have a question on userIDs. The specification states that "The user ID [...] must uniquely identify the user in a container."

From a containers point of view, does this mean that the userID has to be portable between applications? In other words, if gadget A and gadget B (A!=B) are on the same user profile, they MUST receive the same id for the owner?

In our (data) API, we are used to encrypt the userIDs with some application-spec key, and would like to continue to do so for OpenSocial applications. We believe this increases privacy for our users.

[JevS]

Hi.
For me not clear what means 'Support for global and instance-scoped
application data has been removed from the API'.
No more newUpdatePersonAppDataRequest ?
Thanks.
Jevs

[lroh...@gmail.com]

Hi Lane,

I have question.

1. Can use makeRequest() function to upload photo?
2. Can you please give an example if it is possible. (setting headers
etc...)

-Rohan

On Jan 26, 9:11 am, Lane LiaBraaten <api.lliab...@google.com> wrote:

[Reinoud Elhorst]

No. There is no way to upload a photo in javascript. You can use an iframe to upload a photo (but only to your own website, not to the container), and it won't be oauth signed.

[Arne Roomann-Kurrik (Google)]

Hi JevS,

newUpdatePersonAppDataRequest is a Person App Data request (not
Global App Data or Instance App Data). It is still in the 0.7 spec:
http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newUpdatePersonAppDataRequest

There were other methods that most developers were not using that
have been removed.

~Arne

[Arne Roomann-Kurrik (Google)]

Hi Reinoud,

Thanks!

The 0.7 spec makes the following statement about user IDs:

"One of the pieces of data that is always returned with a Person
object is the user's ID. The user ID must be alphanumeric (A-Za-z0-9)
and must uniquely identify the user in a container. This
standardization is intended to allow for prefixing IDs with a domain
name and separator to create globally unique IDs (e.g. "orkut.com:
34KJDCSKJN2HHF0DW20394"). Note that there will likely be a size limit
placed on user IDs to help manage storing IDs in a database."

I think the language is phrased such that any given ID for a user
will need to always point to that user. For example, if user A gets
12345 as an ID for gadget X and 54321 as an ID for gadget Y, both IDs
(12345 and 54321) will always need to point to user A (there should
not be a case where user B gets either ID in gadget Z).

This still allows the possibility of returning different IDs for the
same user, but seems like it doesn't follow the intent of the
specification. I'm following up with the team about this and will
post any new information to this thread.

Cheers,
~Arne

On Jan 28, 11:32 am, "Reinoud Elhorst" <goo...@claude.nl> wrote:
> First of all, congrats on getting out the 0.7 spec!
>
> I have a question on userIDs. The specification states that "The user ID
> [...] must uniquely identify the user in a container."
>
> From a containers point of view, does this mean that the userID has to be
> portable between
> applications? In other words, if gadget A and gadget B (A!=B) are on
> the same user profile, they MUST receive the same id for the owner?
>
> In our (data) API, we are used to encrypt the userIDs with
> some application-spec key, and would like to continue to do so for
> OpenSocial applications. We believe this increases privacy for our
> users.
>

[Reinoud Elhorst]

Arne,

Thanks for your reply. Indeed, the suggestion you make partially covers our usecase. If user A has ID 1234 in gadget X, and 5678 in gadget Y, there is a very large chance that there is not user B in gadget Z with that ID. At the same time though, 1234 not 5678 will point to user A in gadget Z.

The usecase is as follows: If there is some gadget that does something evil (let's say: install malware on the viewers computer through a browser security hole), it will probably send back the viewer's id to it's own site, thereby building a database with userids that have vulnerable browsers and installed malware. If the IDs are gadget-specific, blacklisting that single gadget would invalidate all ids they have collected. If they try again from another url, they will have to start again with an empty database, rather than continue where they were.

Obviously, we'd have to allow for some grouping of gadgets: two different gadgets from the same company will use the same IDs so that they can be matched on their backend.

It would be great if you could clarify the spec's intention here.

Reinoud

[Raul]

Not yet, orkut sandbox is using v0.6

On Jan 27, 10:30 pm, "makaran...@gmail.com" <makaran...@gmail.com>
wrote:

[Reinoud Elhorst]

Arne (or anyone else), I have a second question on the spec that might even be more difficult (since I believe it's part if the gadgets specs rather than the OpenSocial specs).

How are user preferences (gadgets.prefs) to be interpreted? The prefs allow you to set some values, and then if the same user returns to that gadget (possibly on another profile), get those preferences again. I assume that by "the same user", is meant "the same logged in user on the container site".

Now how does this interact with the ability to have access to the viewer information? I believe that as long as the gadget has no access to viewer information, it should not be allowed to get of set user preferences. If it were allowed to do so, it could store the viewer_id in the userprefs if a user granted permission to view its data just once. It would from that point onwards always have access to viewer data, by simply retreiving user preferences.

Would denying setting/getting prefs be allowed withing the OpenSocial standard? Am I perhaps missing something here?

Reinoud