Proposal for 1.0 - Support authenticated iframe mode "type=URL" application

[Jacky Wang (王超)]

Knowing it might be a bit late, but I'm just wondering whether it's
possible to add the proposal "Support authenticated iframe mode
"type=URL" application" into v1.0 spec?

The detailed proposal could be find here:
http://tinyurl.com/iframe-proposal

It could benefit developers a lot if the gadget's behavior matches:

* Most of the communications between gadget and container go through
server-to-server talk rather than JavaScript API.

* Intensive gadget / app server interactions which includes UI
resources, form posting, etc.

* Composed of multiple pages and user navigate between each other
frequently. And, cookie needs to be shared between these pages.

* The transferred data between gadget and app server are very
sensitive that even container should not be able to touch them.

* Wrapping existing page-based web apps into OpenSocial gadget.

* Wrapping existing gadget that has launched on other platform into
OpenSocial one.

This proposal is not a new one - we've discussed around it in this
thread: http://tinyurl.com/iframe-proposal-old-discuss

Thanks to the comments from Kevin, et. al, the proposal is revised
quite a bit since then.

Hopefully it could accepted and benefit to our lovely developers. :)

Thanks,
Jacky

[Edwin Chen]

+1
that a great news, when google will adopt it?

[ma machine]

+1
I am from Ismole in China, we focus in Google Open Social's
development.
I thought this new standards that are very close to the development of
domestic requirements,
Our company is also very much looking forward to this new standard can
be adopted as soon as possible.
It will be helpful to contribute to the more rapid development.

On 11月4日, 下午7时44分, Jacky Wang (王超) <chaow...@google.com> wrote:

[Lane LiaBraaten]

Hi Jackie,

I agree this is a valuable model, but it's really out of scope for this iteration.  I'd suggest pursuing this as an extension so that we can incorporate it in a future iteration. In that regard, the next steps would be to implement your proposed solution and get it running in a container.

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

[Arne Roomann-Kurrik]

Writing an extension specification doc would also be a useful next step.  

Should we try to make a template for spec extension documents?

~Arne

[Lane LiaBraaten]

On Wed, Nov 4, 2009 at 10:56 AM, Arne Roomann-Kurrik <kur...@google.com> wrote:

Writing an extension specification doc would also be a useful next step.  

Should we try to make a template for spec extension documents?

Yeah - a wiki page is probably sufficient.

-Lane

[Jon]

Let's also discuss what parts of the JavaScript APIs are supported.
I'm not aware of any implementation that supports "gadgets.rpc" using
the "libs" parameter of the Gadgets Specification. This is important
for dyanmic-height, and pubsub (when it comes back), and others.

Plus support for any API that is implemented using XMLHttpRequest is
very hard (impossible?) using only what is in the spec.

On Nov 4, 10:58 am, Lane LiaBraaten <lliab...@google.com> wrote:
> On Wed, Nov 4, 2009 at 10:56 AM, Arne Roomann-Kurrik <kur...@google.com>wrote:
>
> > Writing an extension specification doc would also be a useful next step.
>
> > Should we try to make a template for spec extension documents?
>
> Yeah - a wiki page is probably sufficient.
>
> -Lane
>
>
>
> > ~Arne
>

> > On Wed, Nov 4, 2009 at 8:56 AM, Lane LiaBraaten <lliab...@google.com>wrote:
>
> >> Hi Jackie,
>
> >> I agree this is a valuable model, but it's really out of scope for this
> >> iteration.  I'd suggest pursuing this as an extension so that we can
> >> incorporate it in a future iteration. In that regard, the next steps would
> >> be to implement your proposed solution and get it running in a container.
>
> >> Cheers,
> >> Lane
>

> >>> opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-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-gadgets-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-gadgets-spec%2Bunsu...@googlegroups.com>
> > .

[Jacky]

Hi Arne and Lane,

Thank you very much for the reply!! :D

One thing not quite clear - is the purpose of "extension" for
integrating into v.Next spec, or it stands for an independent part?

I'm asking this question since - for the developers, their need is
applying the same spec containing "type=url authz=signed" to most of
the OpenSocial containers. :)

If this model could be included as a extension, and probably has the
chance to be included as a part of the next main spec, it will be
really nice.

Otherwise, it might be still a good idea if we could reconsider
whether it is that fortunate to be included in this round's
discussion, since:
1. it really helps developers, according to our experience gained from
contacting developers closely,
2. even it's not related to "authz=signed", it does help standardizing
the existing "type=url" model,
3. it naturally expands the idea of "type=url".
4. the implementation of this model is not very complicated. If we
decide to put it in, we will have fairly small change on the code
side.

clear document + naturally expanding + straightforward implementation
= happy developer :-)

Thanks in advance!
- Jacky

On Nov 5, 2:56 am, Arne Roomann-Kurrik <kur...@google.com> wrote:
> Writing an extension specification doc would also be a useful next step.
>
> Should we try to make a template for spec extension documents?
>
> ~Arne
>

> On Wed, Nov 4, 2009 at 8:56 AM, Lane LiaBraaten <lliab...@google.com> wrote:
> > Hi Jackie,
>
> > I agree this is a valuable model, but it's really out of scope for this
> > iteration.  I'd suggest pursuing this as an extension so that we can
> > incorporate it in a future iteration. In that regard, the next steps would
> > be to implement your proposed solution and get it running in a container.
>
> > Cheers,
> > Lane
>

> >> opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-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-gadgets-spec%2Bunsu...@googlegroups.com>
> > .