Inline feature proposal for Open Social 2.0

[Grace]

Out team has been working on implementing inlining support in Apache Shindig, and we implemented a separate inline feature. 

The wiki for this proposal is located on the opensocial wiki.

http://docs.opensocial.org/display/OSD/Investigate+spec+changes+to+support+inline+gadgets

Comments and feedback are  welcome!

[Andrew Davis]

Grace,

While I don't agree with the trust assumptions being made in the
corporate environment, a few points of feedback in making this
proposal align with existing features.

- Why change spec on <modulePrefs to use @renderTypesSupported, rather
the just have gadgets request the <require feature="inline"> like caja
does?
- Glad to see you are considering the name space conflicts that are
inherent in this model. Suggest the scope feature not be labeled
"context" as this term is already way overloaded in open social. I
would be more specific in <require feature="inline-scope" or just use
the same feature as above to indicate the gadget requires inline
support <require feature="inline"
-Will the inline feature do any validation for either option A or B to
make sure your scoping semantics are followed, since this is really
requiring the gadget developer to code in the namespace isolation,
versus caja providing the namespace isolation automatically?
-I think one of your main motivations for this inlining proposal is
wanting to support use of dojo in the gadget implementation, which is
not compatible with cajoling? Might be worth adding the to the
proposal.

--Andrew

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

[rbaxter85]

+1 Andrew on @renderTypesSupported.

Goosemanjack had some additional thoughts on the proposal here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/920bfbaf867bdc2f
I asked him to repost to this thread.

He brings up a good point about the namespace "rules" in the
proposal. It should be done automatically and not put the burdon on
the gadget developer. I think the same can be done for the scoping
part of the proposal.

We should also refrain from mentioning iWidgets in the proposal since
some people are not familiar with what they are. Rather we should
expand on the concepts illustrated by iWidgets in the spec.

Also what benefits do we get from providing inlining?

> >http://docs.opensocial.org/display/OSD/Investigate+spec+changes+to+su...

[Grace]

On Thu, Feb 17, 2011 at 10:33 PM, Andrew Davis <andrew...@gmail.com> wrote:

Grace,

While I don't agree with the trust assumptions being made in the
corporate environment, a few points of feedback in making this
proposal align with existing features.

- Why change spec on <modulePrefs to use @renderTypesSupported, rather
the just have gadgets request the <require feature="inline"> like caja
does?  

 

Actually we considered this way  and also have the implementation. But further thought, we need the gadget developer to indicate whether or not the gadget supports being inlined ... this allows gadgets to be removed from consideration for being inlined, but by itself will never cause a gadget to be inlined. We need site/page administers to indicate whether or not a specific instance of a gadget which supports being inlined will actually be inlined. If using this require way, the inline related features will be loaded, but if the gadget can't be inlined, it is not necessary.  So we introduce @renderTypesSupported which indicates whether the gadget can be inlined; the reference placing the gadget in the page can indicate whether or not to inline it by passing a renderParameter named renderType, such as : myContainer.navigateGadget(gadgetSite0, gadgetUrls[0], {view:'profile'}, {height:300,renderType:'inline'}); the whole page can indicate whether or not to inline the whole page's gadgets by pass a parameter named renderType, such as : 

<script type="text/javascript" src="../gadgets/js/container:rpc:inline.js?c=1&debug=1&container=default"&renderType=inline></script>

; the site can set the whole server's render type policy on server side by configuration in shindig.properties. Add an configuration named "shindig.renderType".

 

- Glad to see you are considering the name space conflicts that are
inherent in this model.  Suggest the scope feature not be labeled
"context" as this term is already way overloaded in open social.  I
would be more specific in <require feature="inline-scope" or just use
the same feature as above to indicate the gadget requires inline
support <require feature="inline"

 Thanks for the suggestions.

 

-Will the inline feature do any validation for either option A or B to
make sure your scoping semantics are followed, since this is really
requiring the gadget developer to code in the namespace isolation,
versus caja providing the namespace isolation automatically?

The inline feature will check whether the gadget supports scoping, if not, only one instance can be supported.

 

-I think one of your main motivations for this inlining proposal is
wanting to support use of dojo in the gadget implementation, which is
not compatible with cajoling? Might be worth adding the to the
proposal.

The most benefit we can get from inlining is to improve performance, especially on mobile devices.   

[Grace]

Thanks! I saw Goosemanjack's thoughts. we also consider the way automatically resolve the namespace conflict, but seems it is more difficult. For example: if gadget developer defines a method A in gadget.xml, the render server need replace the method A's declaration and call methods to make sure it only applies to that instance. The global replacement is not very well.  So we suggest the gadget developer scoping the methods himself and the render server will be responsible to create instance of the scoping object.

Regarding to move the attribute to security policy feature, seems it is suitable considering the environment. But personally I think they are separate features, and inline is also a significant features.  Will the security policy feature be moving to core gadget spec?

Performance improvement is a significant benefit from proving inlining.

[goosemanjack]

(moving comments from other thread to this one)

Starting a thread on Inline gadgets.

Current proposal here:

http://docs.opensocial.org/display/OSD/Investigate+spec+changes+to+su...

Current proposal suggests adding @renderTypesSupported attribute to
ModulePrefs tag, and manual DOM element ID manipulation by gadget
developer.

=== from current proposal ===
<ModulePrefs title="hello world" renderTypesSupported="inline,
iframe">
Prefix all the fixed DOM id with _MODULE_ID
=== end from current proposal ===

IMO, this functionality should be exposed as part of the security-
policy feature, not as an attribute heaped on the ModulePrefs tag.
Inline vs. iFrame vs. iFrame in jail domain is ultimately a security
consideration. Fully-trusted gadgets could be completely rendered
inline. Partially trusted gadgets could also be rendered inline if
they are scrubbed of script.

Levels of render trust I see are:

* Untrusted - render as iFrame in Jail domain
* Partial Trust Isolated - render as iFrame to avoid DOM and CSS
collision, jail domain optional
* Partial Trust Inline - render inline with no client
container and all client script stripped out
* Full Trust Inline - render directly inline allowing
scripts

One of the trickiest parts of inline rendering is DOM and CSS
isolation. IMO asking the developer to manually control the DOM
element IDs is the wrong path for two reasons:

1. It is error-prone b/c gadget developers will "forget" or will
ignore this requirement.
2. It disallows multiple instances of the same gadget rendered on the
same page.

DOM and CSS ID manipulation must be handled programmatically to
overcome the two above issues. It's a tricky problem, though, and we
may be able to simply make a recommendation to gadget authors and punt
this aspect to a later spec version.

Currently security policy is defined in the template portion of the
spec. We should also move it to the core gadget spec.

http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Te...

The security policy only deals with EL escaping behavior in its
current form, but was specifically designed as a module feature to be
extensible. Through additional <param> tags we can extend this to
allow the gadget developer to request inline rendering and any
additional features required.

ex:
<ModulePrefs >
<Optional feature="security-policy">
<Param name="render_inline" >home</Param>
<Param name="render_inline_noscripts" >profile</Param>
</Optional >
</ModulePrefs >

The above syntax allows for finer grained control of rendering
mechanisms on a per-view basis.

On Feb 18, 12:54 am, Grace <qiaoy...@gmail.com> wrote:
> Thanks! I saw Goosemanjack's thoughts. we also consider the
> way automatically resolve the namespace conflict, but seems it is more
> difficult. For example: if gadget developer defines a method A in
> gadget.xml, the render server need replace the method A's declaration and
> call methods to make sure it only applies to that instance. The global
> replacement is not very well.  So we suggest the gadget developer scoping
> the methods himself and the render server will be responsible to create
> instance of the scoping object.
>
> Regarding to move the attribute to security policy feature, seems it is
> suitable considering the environment. But personally I think they are
> separate features, and inline is also a significant features.  Will the
> security policy feature be moving to core gadget spec?
>
> Performance improvement is a significant benefit from proving inlining.
>

> On Fri, Feb 18, 2011 at 9:05 AM, rbaxter85 <rbaxte...@gmail.com> wrote:
> > +1 Andrew on @renderTypesSupported.
>
> > Goosemanjack had some additional thoughts on the proposal here:
>

> >http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

[goosemanjack]

If you're using a sandboxing technology like Caja or Web Sandbox, the
rewrite of DOM elements and JS references to them is handled by the
sandbox transform, so it is technically feasible to programmatically
handle this action. That said, I don't want to see this feature as a
back-door to forcing Caja into the OpenSocial spec. Naming Caja
explicitly as _the_ sandboxing technology to use will create problems
down the road if a new, better sandbox comes along. While these
technologies are impressive, all the implementations I've seen have
significant flaws. Hopefully browsers at some point will natively
implement javascript sandboxing technology, but I digress.

If this is a concern for folks, we could create some sort of hook for
the gadget to ask for a particular sandbox or request a general
"sandbox" from the container. I suppose what the gadget developer
really needs would be a way to tag their gadget at "caja-safe", as
in "confirmed that it actually runs correctly if you use caja". Of
course, if a container is using Web Sandbox or some other technology,
that flag is somewhat meaningless.

> <script type="text/javascript"
> src="../gadgets/js/container:rpc:inline.js?c=1&debug=1&container=default"&renderType=inline></script>
> ; the site can set the whole server's render type policy on server side by
> configuration in shindig.properties. Add an configuration named
> "shindig.renderType".

This seems to be the wrong approach, as it is more of a shotgun
approach whereas we need a rifle. Setting a global value to inline
gadgets means the environment won't be able to execute both trusted
and untrusted gadgets.

The inlining support really should be configurable at view surface
granularity.

It's easy to understand that fully trusted and verified gadgets should
be allowed to render inline for performance and display (ex: shared
styling, background elements, etc) reasons. But a partially trusted
or untrusted gadget might also be a candidate for inlining if there is
no use of client-side features and no script on a particular view
surface. An object example would be the Home view (small view) of a
gadget that simply displays some statistics from an endpoint and
contains a link to the main canvas. The needs of the Home surface
could easily be satisfied with OSML templates, EL, and data pipelining
without any client-side processing. Inlining this content gives
better page performance due to the lack of an extra iFrame and a more
integrated display experience.

On the flip side, many gadgets make an assumption about being the only
thing running on the page. As such, they may tie in to page-level
script events in a sloppy way, like overwriting the onload event
instead of registering a load handler with the gadget framework.
Forcing these gadgets to suddenly run inline via a global setting is
going to break some of them. Control really should be in the hands of
the gadget developer so they can determine if their code is safe to
inline or must run in isolation.
--
clc

[Mark W.]

+1 on Chris's comments from cross posting in this thread:

https://groups.google.com/d/topic/opensocial-and-gadgets-spec/kgv7r4Z73C8/discussion

I've also added a feature request for the security policy

http://code.google.com/p/opensocial-resources/issues/detail?id=1143

[goosemanjack]

Created a patch to move the security policy section from template spec

to the core gadget spec.

On Feb 23, 9:22 am, "Mark W." <weitzelm.w...@gmail.com> wrote:
> +1 on Chris's comments from cross posting in this thread:https://groups.google.com/d/topic/opensocial-and-gadgets-spec/kgv7r4Z...

[Evgeny Bogdanov]

Hello everyone, 

What is the progress on inline gadget rendering?
was it added to the specification.

I couldn't find it.

[Ryan Baxter]

No and I don't think anyone is working on it anymore.