[Update] Revising the compliance section

[Lane LiaBraaten]

Hey Folks,

I've been doing some more thinking about how to revise the compliance section, and I have a proposal that's ready for feedback on the wiki [1].  In short, the proposal defines the following four levels of compliance:

• OpenSocial Container
  • meets Social Gadget Container criteria
  • meets OpenSocial Server criteria
• OpenSocial Server
  • MUST support REST
  • MAY support RPC
• Social Gadget Container
  • meets Gadget Container criteria
  • supports opensocial/osapi.* JavaScript
  • supports OSML
• Gadget Container
  • can render gadgets
  • supports the gadgets.* JavaScript
  • supports Templating
  • supports Data Pipelining

The actual spec patch will be pretty small (see [1] for proposed text), but I wanted to shop this compliance model around and make sure it will work for everyone.

Thanks,
Lane

[1] http://wiki.opensocial.org/index.php?title=Revise_the_compliance_section

[Jon]

I think these are the right divisions, the references to the documents
are not so clear. I'll be taking a pass at trying to clarify them.

Should extensions be a MUST - not clear on that.

On Nov 4, 12:24 pm, Lane LiaBraaten <lliab...@google.com> wrote:
> Hey Folks,
>
> I've been doing some more thinking about how to revise the compliance
> section, and I have a proposal that's ready for feedback on the wiki [1].
> In short, the proposal defines the following four levels of compliance:
>

>    - *OpenSocial Container*
>       - meets Social Gadget Container criteria
>       - meets OpenSocial Server criteria
>    - *OpenSocial Server*
>       - MUST support REST
>       - MAY support RPC
>    - *Social Gadget Container*
>       - meets Gadget Container criteria
>       - supports opensocial/osapi.* JavaScript
>       - supports OSML
>    - *Gadget Container*
>       - can render gadgets
>       - supports the gadgets.* JavaScript
>       - supports Templating
>       - supports Data Pipelining

[Lane LiaBraaten]

One thing I need to change is that data pipelining should really be under "Social Gadget Container" since all the tags are for people/activities/etc except HttpRequest.  HttpRequest is pretty much equivalent to the <Preload> tag in the Gadget XML, so I think it'll be okay to just have "Gadget Containers" support that.

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

[Jon]

Not really, here's my view of os:DataRequest (as I plan to do when we
separate Gadgets and OS):

It's very generic, says nothing about the application. DataRequest is
some type of accessor to the local server data, whereas MakeRequest
accesses remote content.

For the Gadget spec part, it would simply exist as a protocol with no
supported values.

OS would require support for os:DataRequest/@method being one of
{people.get, actvities.get}

OS would extend pipelineing with os:PeopleRequest, os:ViewerRequest...

Containers like eBay's would extend the method with our proprietary
APIs: Shopping, Trading, etc... This way we can take all the data
returned by them, and use them in pipelining, EL, and templates, just
like OS would use PeopleRequest and others

Then we also have mappings to RPC, REST in a very similar way. One day
perhaps, this eCommerce API, could become a standard like OS, but
that's far down the line. Just trying to establish a path using an
establish framework.

On Nov 4, 2:02 pm, Lane LiaBraaten <lliab...@google.com> wrote:
> One thing I need to change is that data pipelining should really be under
> "Social Gadget Container" since all the tags are for people/activities/etc
> except HttpRequest.  HttpRequest is pretty much equivalent to the <Preload>
> tag in the Gadget XML, so I think it'll be okay to just have "Gadget
> Containers" support that.
>
> -Lane
>

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com>
> > .

[Lane LiaBraaten]

Cool - sounds like I had it right the first time :)

-Lane

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[Jon]

Taking another read of the compliance section, 3.1 says "The container
must implement all methods in Section 5...Methods may return the error
code opensocial.ResponseItem.NOT_IMPLEMENTED..."

Section 3.2 discusses extensions.

Will you still include them?

[Lane LiaBraaten]

This is not to say that containers MUST implement any extensions, but when they do, they MUST follow the guidelines/requirements define in the extensions section.

The existing "extensibility" part of the compliance section mostly pertains to the JavaScript API that we're deprecating so I think we should remove it.  There may, however, be some language in the extensions section that deals with naming conventions for namespaces, objects, fields, or methods used in extensions.

-Lane