Inline gadget proposal

[goosemanjack]

Starting a thread on Inline gadgets.

Current proposal here:

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

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-Templating.xml#rfc.section.6

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.

[rbaxter85]

Googsemanjack, Grace started a thread here.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/ff1ceba8a99c9338
You should repost your comments there.

On Feb 17, 2:29 pm, goosemanjack <cc...@myspace.com> wrote:
> Starting a thread on Inline gadgets.
>
> Current proposal here:
>

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

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

[goosemanjack]

Closing this thread down and posting on the live thread. Please add
all comments on the other thread!!!










On Feb 17, 4:50 pm, rbaxter85 <rbaxte...@gmail.com> wrote:
> Googsemanjack, Grace started a thread here.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

[Mark W.]

+1 for moving security policy.

I opened a feature request for this: http://code.google.com/p/opensocial-resources/issues/detail?id=1143