OpenSocial 3.0 kickoff, proposals page...

[Mark W.]

Greetings all...

Matt, Andy, and I met this morning and worked a on getting organized for 3.0 kickoff. I'm excited to say that it is shaping up nicely.

We've got the 3.0 proposals page in place and have added the ones we know will be coming down the pipe. We'll make each entry a link to the OpenSocial resources as we add to it. 

If you have not signed up, and are planning to attend, either in person or via web con, make sure you RSVP on eventbrite. 

[Henry Saputra]

Why does OpenSocial have to follow "what does twitter do?" for the REST APIs?

- Henry

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/U1RmWZiXigYJ.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Matthew Marum]

That was part of a discussion about what other REST APIs do to handle versioning.  That really should read "What do other REST APIs (like Twitter) do?"

We'd prefer to follow the industry trend, if there is one.  But I don't think there is one that doesn't have drawbacks.

Matt

[iamahern]

Hi Mark,
I have no wiki access yet so here is the shortlist of what comes to
mind..

1. UserPrefs & AppData
What ever happened with this http://docs.opensocial.org/display/OSD/UserPrefs+vs+AppData?
Looking at gadgets in the wild (iGoogle) many gadgets do not declare
their dependency on setPrefs, but implicitly expect the Container to
provide a UI for setting preferences to function. I would like to see
clarity around what form of UI the container should provide to support
setting preferences for gadgets and finer grained scoping to user
preferences. Being new to this, it could also be that I am just
missing a sentence spec clarity on when and what should AppData be
utilized for.

2. Large File Download
Most of this implementation issue, but large file download fails
utterly in Shindig today (since the internals buffer the entire
resource in Memory in Shindig Java). The reason for the buffering,
touching on one of Jame's notes, is around the way the Container needs
to handle caching and potentially batching requests (where it may need
to drop the contents into sequential sections of a JSON return). If
that function is to continue, gadgets which need to authorize the
download of large binary objects really need a way to create requests
that have a clean pipe through the proxy - which is not possible
today. Alternatively, we could define a standard practice / protocol
for signing requests that can be executed directly against the
download host without proxy involvement.

3. Cross container data requests
I probably just need a pointer to an email thread, but this use case
seemed potentially useful: http://docs.opensocial.org/display/OSD/Cross+Container+Data+Requests.
This is fairly low on my priority list. The major use case is trying
to reuse an ActivityStream gadget in another container. The gadget
itself should be compliant and reusable, but you may wish it to
display data from the home data API irregardless of the container that
it is utilized in.

4. Spaces Proposal
I have seen this one fly by on the mailing list and I have to admit
that I didn't read it thoroughly. However +1 to the concept - it is a
critical use case for the specification to address for my
constituents.

5. Access Control
This is a big elephant so I'll leave it to the imagination to an
extent. This relates to the one above, basically I have not seen a
consistent way in which data element access should be scoped. In the
3.0 timeframe I do not have major requirements around this (yet), but
I am calling it out primarily as it relates to Spaces (which is not on
the 3.0 list) and People (which I did see on the 3.0 list).

6. Data API Extensibility
AppData does a decent job covering this and the issue has been touched
on piecemeal for ActivityStreams uses cases. I would like to see
formality in the way in which one should go about adding extensions to
OS Social Data and a formal way in which clients dependent on it
should read these elements. This one is also fairly low priority.

Regards,
-Mike

On Feb 3, 11:32 am, "Mark W." <weitzelm.w...@gmail.com> wrote:
> Greetings all...
>
> Matt, Andy, and I met this morning and worked a on getting organized for
> 3.0 kickoff. I'm excited to say that it is shaping up nicely.

> We've got the 3.0 proposals page<http://docs.opensocial.org/display/OSD/Spec+Changes+-+v3.0>in place and have added the ones we know will be coming down the

> pipe. We'll make each entry a link to the OpenSocial resources as we add to
> it.
>
> If you have not signed up, and are planning to attend, either in person or

> via web con, make sure you RSVP on eventbrite<http://opensocial30.eventbrite.com/>
> .

[Evgeny Bogdanov]

1. We had a discussion on this topic and it is true that UserPrefs depend on the container (container should implement it in addition to shindig). 

The UserPrefs are needed if container does not implement any OpenSocial apis (appdata, people, etc), in other words for core-gadgets.

However, UserPrefs also limit some scenarios of use.

I am personally in favor of having a feature that would imitate UserPrefs via appdata calls and these user prefs live inside the gadget and not in the container.

4. Space proposal is here:

http://docs.opensocial.org/display/OSD/Space+Proposal

any feedback would be much appreciated and I am ready to improve it further and move my shindig-2.0 implementation to current version of shindig, once we agree more or less on the spec.

The patch to the spec is here: http://iamac71.epfl.ch/os_space/

[halv0112]

If you want access to the wiki please go create an account then send a note to wikiadmin (at) opensocial.org and I will give you edit rights.