Question on Section 9 of Gadgets Spec...

[Mark W.]

In the current preview of the gadgets spec, section 9.2 defines the
optional features. OpenSocial is the first optional feature. So this
kinda makes sense and kinda doesn't.

So I understand that what we are saying is that you don't need
opensocial to do gadgets. It's, well, optional.
However, it's required if you are doing gadgets with social stuff.

What I would propose is that we remove it from the table in 9.2. One
of the objectives was to make sure we had a clean separation b/t
gadgets and opensocial. This would also make it consistent with the
compliance section.

If we wanted, in the Social-Gadget.xml file, we could then add the
same notion of Core and Optional and introduce a section similar to
9.1 and 9.2 from the Gadgets spec. I'm not exactly sure how it would
look, but maybe the templating section would not be part of core.

http://www.opensocial.org/Technical-Resources/draft/OpenSocial-Gadget-XML.xml#Module

-Mark W.

[Lane LiaBraaten]

On Wed, Nov 18, 2009 at 9:53 AM, Mark W. <weit...@us.ibm.com> wrote:

In the current preview of the gadgets spec, section 9.2 defines the
optional features. OpenSocial is the first optional feature. So this
kinda makes sense and kinda doesn't.

So I understand that what we are saying is that you don't need
opensocial to do gadgets. It's, well, optional.

It's optional as far as Core-Gadget.xml is concerned, so it seems fine to include in this table.

 

However, it's required if you are doing gadgets with social stuff.

Then it's 'required' as far as the Social-Gadget.xml -- really, the Social-Gadget spec will just say that to get all this extra javascript, the gadget must require the opensocial feature.

Does that work for you?

-Lane

 

What I would propose is that we remove it from the table in 9.2. One
of the objectives was to make sure we had a clean separation b/t
gadgets and opensocial. This would also make it consistent with the
compliance section.

If we wanted, in the Social-Gadget.xml file, we could then add the
same notion of Core and Optional and introduce a section similar to
9.1 and 9.2 from the Gadgets spec. I'm not exactly sure how it would
look, but maybe the templating section would not be part of core.

http://www.opensocial.org/Technical-Resources/draft/OpenSocial-Gadget-XML.xml#Module

-Mark W.

--

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.

[Mark W.]

OK, so I think what I'm pushing on is this...
The things that are "optional" in the gadget spec are all defined in
the gadgets namespace. opensocial is not. It's going to introduce a
new namespace. It seems that the gadget spec (and maybe all the specs)
should state what is required/optional for the things defined within
its scope. Following this line of thought, the social gadget spec
should define the opensocial namespace and state which things inside
of it are required (in this case, all of it).


As we go forward, in order to be consistent, every time we add
something to the spec, say micro payments, would we have to update the
gadget spec to say this one is optional?

-Mark W.

On Nov 18, 2:27 pm, Lane LiaBraaten <lliab...@google.com> wrote:

> On Wed, Nov 18, 2009 at 9:53 AM, Mark W. <weitz...@us.ibm.com> wrote:
> > In the current preview of the gadgets spec, section 9.2 defines the
> > optional features. OpenSocial is the first optional feature. So this
> > kinda makes sense and kinda doesn't.
>
> > So I understand that what we are saying is that you don't need
> > opensocial to do gadgets. It's, well, optional.
>
> It's optional as far as Core-Gadget.xml is concerned, so it seems fine to
> include in this table.
>
> > However, it's required if you are doing gadgets with social stuff.
>
> Then it's 'required' as far as the Social-Gadget.xml -- really, the
> Social-Gadget spec will just say that to get all this extra javascript, the
> gadget must require the opensocial feature.
>
> Does that work for you?
>
> -Lane
>
>
>
>
>
> > What I would propose is that we remove it from the table in 9.2. One
> > of the objectives was to make sure we had a clean separation b/t
> > gadgets and opensocial. This would also make it consistent with the
> > compliance section.
>
> > If we wanted, in the Social-Gadget.xml file, we could then add the
> > same notion of Core and Optional and introduce a section similar to
> > 9.1 and 9.2 from the Gadgets spec. I'm not exactly sure how it would
> > look, but maybe the templating section would not be part of core.
>

> >http://www.opensocial.org/Technical-Resources/draft/OpenSocial-Gadget...

>
> > -Mark W.
>
> > --
>
> > 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<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> > .

[Kevin Brown]

On Wed, Nov 18, 2009 at 11:27 AM, Lane LiaBraaten <llia...@google.com> wrote:

On Wed, Nov 18, 2009 at 9:53 AM, Mark W. <weit...@us.ibm.com> wrote:

In the current preview of the gadgets spec, section 9.2 defines the
optional features. OpenSocial is the first optional feature. So this
kinda makes sense and kinda doesn't.

So I understand that what we are saying is that you don't need
opensocial to do gadgets. It's, well, optional.

It's optional as far as Core-Gadget.xml is concerned, so it seems fine to include in this table.

 

However, it's required if you are doing gadgets with social stuff.

Then it's 'required' as far as the Social-Gadget.xml -- really, the Social-Gadget spec will just say that to get all this extra javascript, the gadget must require the opensocial feature.

As I understand the current state of things, the "opensocial" feature is only still needed because there were some remaining functions that weren't satisfied by either osapi or anything in gadgets core. Wouldn't it be easier to resolve this, and make the osapi-styled APIs fill this role (and hopefully eliminating the confusion of requiring "opensocial" in the process)?
 

[Mark W.]

This sounds like a reasonable approach to me. Do we know which APIs
are not covered?

Lane,
As the overall "shepherd" of 1.0, what do you think?

-mw

On Nov 18, 4:18 pm, Kevin Brown <e...@google.com> wrote:
> On Wed, Nov 18, 2009 at 11:27 AM, Lane LiaBraaten <lliab...@google.com>wrote:

> >>http://www.opensocial.org/Technical-Resources/draft/OpenSocial-Gadget...

>
> >> -Mark W.
>
> >> --
>
> >> 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<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
> >  --
> > 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<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> > .

[Lane LiaBraaten]

I don't see how moving things to osapi solves anything...if we did that we'd be asking should we include "osapi" in that list, instead of "opensocial".

This comes down to an 'extensions' question, as these optional gadget libraries are really "accepted extensions" (being grandfathered in).  For each revision of the spec we should include a list of accepted extensions (though I'm not sure where the best place for that list is).

In this light, the "opensocial", "osapi", "opensocial-data", etc, features aren't like the others.  Yes, they're optional, but they're covered other parts of the "OpenSocial Spec" (meaning the collection of spec files).  So I think it's okay to just exclude them from this table.

Open Question: Should we leave these optional features where they are, or move them into their own "extension spec" to dogfood our new extension concepts?

-Lane 

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=.

[Jon]

> Open Question: Should we leave these optional features where they are, or
> move them into their own "extension spec" to dogfood our new extension
> concepts?

The content for Section 9 is good, but there should be 2 "section 9"s.
One for "Core" and one for "Social".

As a documentation standard we have X-Data, X-Gadget, X-API-Server (is
the future plan to move Gadget-XML to Core-Gadget?). Since these refer
to the JavaScript APIs (and only JS APIs?) each X-Data should properly
define the optional features within the scope of "X". (and the reverse
should be true, features outside the scope of "X" should not be
mentioned, unless required for dependency which is a completely
different concept)

As to where do we document accepted standards? We don't have that
problem for 1.0. But tentatively we could put it in the compliance
section. For instance if pubsub becomes an accepted extension, we will
place a line in the compliance section referencing the document and
version incorporated as part of OS Vx.y.

[Lane LiaBraaten]

On Wed, Nov 25, 2009 at 9:17 AM, Jon <jon.we...@gmail.com> wrote:

> Open Question: Should we leave these optional features where they are, or
> move them into their own "extension spec" to dogfood our new extension
> concepts?

The content for Section 9 is good, but there should be 2 "section 9"s.
One for "Core" and one for "Social".

As a documentation standard we have X-Data, X-Gadget, X-API-Server (is
the future plan to move Gadget-XML to Core-Gadget?).

Yes...I'm hoping to send out a patch/preview of the merged Core-Gadget and Gadget-XML today.

 

Since these refer
to the JavaScript APIs (and only JS APIs?)

X-Gadget includes anything that can go in a gadget: JS, Data Pipelining, Templating.  Since "features" (in the Require feature="foo" sense) go in gadgets, I think they should be covered in X-Gadget.  If they define any new data types, then those would go in the X-Data file.

 

each X-Data should properly
define the optional features within the scope of "X". (and the reverse
should be true, features outside the scope of "X" should not be
mentioned, unless required for dependency which is a completely
different concept)

As to where do we document accepted standards? We don't have that
problem for 1.0. But tentatively we could put it in the compliance
section. For instance if pubsub becomes an accepted extension, we will
place a line in the compliance section referencing the document and
version incorporated as part of OS Vx.y.

I think a list of accepted extensions is appropriate for the "Extensions" section of the main spec doc (since even 'accepted' extensions are optional).

-Lane 

--

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.