[OS 3] Tieing APIs To Features

[Ryan Baxter]

I was talking to a novice gadget developer a while ago and he posed an
interesting question. "How do I know what features to require when I
want to use certain APIs?" I did not really have a good answer for
him. Section 4.1.1.1 of core gadget has a nice table which maps
javascript namespaces to feature names which is nice, but this is only
for some of the core apis. What if I wanted to use APIs in the osapi,
or opensocial.data namespases? I didn't see anywhere in the specs
that called out what features I need in order to use those APIs. As
part of the cleanup for OpenSocial 3.0 I would like to see any easy
way to identify what features I need to use in order use certain
APIs. Thoughts?

[Ryan Baxter]

[Matthew Marum]

I think every JavaScript API in the spec should have a reference or a link to the Feature that includes it.

Matt

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
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.

[Henry Saputra]

Hmm I remember there is OS versioning support for the features?

HS

[Matthew Marum]

There is versioning in the spec for features but I haven't seen it widely used.

Matt

[Mark W.]

Ryan,

We should do this and work with the shindig community to make the structure of shindig a bit easier to consume as well. Andy Smith was going to post something on that list b/c we talked about this last Friday. 

Also, as Matt points out, there is feature versioning in the spec, but it's, regrettably, not implemented in Shindig yet. I don't think it would be that hard, it's just not done yet.

 

[Ryan Baxter]

I dont see what feature versioning has to do with defining what
features container which APIs. (Well maybe it does as we add
different features, but I am talking at a higher level.) Its
difficult to find out what features I need to require to use which
API. Sometimes the feature name is only mentioned in the example,
sometimes its there in the text of the spec, sometimes its not there
at all. I just want a clear place to go once I know what API I want
to use to find out what feature I need.

[Matthew Marum]

I thought I already posted this somewhere else but I agree.  I think every API in the spec should have a link/reference to the feature name that included it.

I also agree that Shindig could be better structured to ease adoption and understanding of OpenSocial.

Matt

[Ryan Baxter]

Thanks Matt, glad we are on the same page. We should push this
forward into a 2.5 release, does that seem reasonable?

[Mark W.]

So I think we are on the same page with the problem?

Let's just bring this into 3.0 and add it to the kickoff.

[Andy Smith]

+1  to Ryan's suggestion.  There certainly needs to be more clarity at the specification level.  Mark, Matt and I talked a little about this last week regarding how we organize the structure in Apache Shindig.  Today, features are either in features or extras.  It would be nice if we grouped these logically.  This was the first pass at the logical grouping:

Features

Features Incubating

Features Core

Extras Experimental

Libraries (Dojo, JQuery, etc)

Deprecated (6-1.0)

,

On Tue, Feb 7, 2012 at 8:42 PM, Mark W. <weitze...@gmail.com> wrote:

So I think we are on the same page with the problem?

Let's just bring this into 3.0 and add it to the kickoff.

--

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/-/ST_CibKqvm4J.

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.

--
Thank you,

Andy

[Ryan Baxter]

Seems like the right approach Andy. I would argue this is something
we can do for 2.5 since we will essentially just adding a table(s).

On Feb 8, 6:44 am, Andy Smith <and...@gmail.com> wrote:
> +1  to Ryan's suggestion.  There certainly needs to be more clarity at the
> specification level.  Mark, Matt and I talked a little about this last week
> regarding how we organize the structure in Apache Shindig.  Today, features
> are either in features or extras.  It would be nice if we grouped these
> logically.  This was the first pass at the logical grouping:
>
> Features
> Features Incubating
> Features Core
> Extras Experimental
> Libraries (Dojo, JQuery, etc)
> Deprecated (6-1.0)
>

> *
>
> *

> ,
>
>
>
>
>
>
>
>
>
> On Tue, Feb 7, 2012 at 8:42 PM, Mark W. <weitzelm.w...@gmail.com> wrote:
> > So I think we are on the same page with the problem?
>
> > Let's just bring this into 3.0 and add it to the kickoff.
>
> > --
> > 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/-/ST_CibK...
> > .

[Andy Smith]

+1, agree this seems pretty straight forward.

[Henry Saputra]

Ah got it =)

I thought you were concern what features and APIs available for
certain OS version.

Apologize about the misunderstanding.

+1 for the idea.

- Henry