PROPOSAL for v.Next : Opensocial Flash tag
Louis Ryan
I'd like to propose an OpenSocial Flash tag, <os:Flash> to allow developers to safely and consistently include flash content in their gadgets and allow containers to mandate the behavior and version of Flash used. Basic format is
<os:Flash ...><alternate markup></os:Flash>
<alternate markup> is displayed when a browser does not have flash support or when play="onclick".
The tag has the following attributes:
swf : The Uri of swf file to display
id : The id of the DOM 'object' tag which loads the flash content. It is expected that flash is loaded in an 'object' tag and not using 'embed' or 'img'.
name : Copied to the 'name' attribute of the generated 'object' tag.
class : Copied to the 'class' attribute of the generated 'object' tag.
width : Copied to the 'width' attribute of the generated 'object' tag.
height: Copied to the 'height' attribute of the generated 'object' tag.
play : [immediate | onclick]. "immediate" implies the content is played immediately. "onclick" implies that the alternate content is shown and the flash is not loaded and played until the user clicks on the alternate content
scale : [showall | noborder | exactfit | noscale]
wmode : [window | opaque | transparent | direct | gpu]
devicefont : [true | false]
swliveconnect : [true | false]
allowscriptaccess : [ always | samedomain | never ]
allownetworking : [ all | internal | none ]
loop : [true | false]
quality : [ best | high | medium | autohigh | autolow | low ]
align : [middle | left | right | top | bottom ]
salign : [ tl | tr | bl | br | l | t | r | b ]
bgcolor : Copied to the 'bgcolor' attribute of the generated 'object' tag.
seamlesstabbing : [true | false]
allowfullscreen : [true | false]
flashvars : Form encoded query string. The security token of the rendered gadget is always appended to this using the param name "st".
Support for this feature is primarily derived from the swfobject JS library http://code.google.com/p/swfobject/ which has become the de facto standard for Flash scripting and cross-browser support.
It should be noted thats EL expressions are resolved in the tag attributes, this is particularly useful for flashvars as it allows the results of Data Pipelining requests to be bound. Because flashvars require form encoded content additional EL functions are needed to form-encode content prior to including it in the result. Consider
<!-- Fetch a user profile using data pipelining -->
<script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data">
<os:PeopleRequest key="me" userId="@me"/>
</script>
...
<os:xFlash swf="<swf>" flashvars="me=${os:UrlEncode(me)}">
<b><p>alternate content. Click me!</p></b>
</os:Flash>
The tag also allows containers to control behavior of flash when the gadget is rendered in a sanitized view. In this case a container can choose to more tightly sandbox flash to prevent it interacting with the browser by forcing allowscriptaccess=none, allownetworking=internal & swliveconnect=false. This would allow flash to run and have access to social data via REST/RPC using the injected security token as well as injected pipelined data without interacting with the browser, i.e no Phishing redirects.
A sample implementation of this is checked into Shindig as an extension and uses the tag name os:xFlash and supports the EL functions os:xUrlEncode & os:xUrlDecoder.
Best
-Louis
Scott Seely
If we do os:Flash, we should probably handle os:Silverlight too. Do we want to tackle these as a pair or separate?
Louis Ryan
Lev Epshteyn
I'm also strongly in favor of the idea of built-in EL functions, as these are very useful for all kinds of formatting (date comes to mind).
But why such strange syntax? I specifically mean the colons in the names. This seems like it may get confused with the ternary operator. If we want namespacing in the functions, why not use the dot notation:
${os.urlEncode(foo)}, ${os.formatDate(viewer.birthDay, 'MMM DD, YYYY')}, etc?
Louis Ryan
Scott Seely
Looking at the markup, I think our earlier resolution to the discussion of extension methods is flawed. I don’t know that the mechanism we discussed is the cleanest way to say “this feature is non-portable”. Consider the markup for the Flash example:
<os:xFlash swf="<swf>"
flashvars="me=${os:UrlEncode(me)}">
<b><p>alternate content. Click
me!</p></b>
</os:xFlash>
It reads as though it is an optional feature in the OpenSocial spec (like gadgets and MiniMessage). It isn’t—instead, it is a container specific extension to OSML and is not portable between containers. I would expect some other things in place:
1. An imported template library (I understand that this was not chosen due to other concerns in rendering Flash content).
2. A <Require feature="shindig-opensocial-extensions" /> marker to indicate that this gadget uses extensions known to Shindig.
(Or a <Require feature="myspace-opensocial-extensions" /> marker to indicate that this gadget uses extensions known to MySpace.)
Does this make sense? Otherwise, a gadget would fail because an unsupported feature was attempted to enter the container.
Oh—what in the world is os:UrlEncode? There were other typos in the markup (your markup tries to balance <os:xFlash> with </os:Flash>), so this might be a goof.
From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Louis Ryan
Sent: Thursday, April 02, 2009 12:53 AM
To: OpenSocial - OpenSocial and Gadgets Specification Discussion
Louis Ryan
The example has a typo, should have read
<os:Flash swf="<swf>" flashvars="me=${os:UrlEncode(me)}">
Dave Westwood
How can we show a different version of the flash swf files depending on the version of the Flash player? We have a different build of BuddyPoke for Flash 9 and Flash 10. The Flash 10 version has more functionality. The percentage of users with Flash 10 is not yet high enough for us to simply switch to a single Flash 10 build.
For a sanitized view, with allownetworking set to internal how can we do things like Flash-based Google Analytic Events? I expect analytics uses different domains, which means it wont work. (And I think Google Analytics might also use the external interface?) Analytics is particularly important for developers. We've started to do branded content (Wolverine on Orkut) and it's important for the client to know how often their pokes are used etc.
Will a sanitized canvas view still allow banner ads + virtual payments? Companies like PeanutLabs have *Flex* based payment solutions that can be used on the Canvas view. With a sanitized canvas view and allownetworking=internal I expect this will break their implementation. The canvas view on most apps can contain flash-based banner ads on the same page. How would these be sanitized? Wouldn't banner ads pose a bigger risk than the actual app?
Thanks
Dave
Scott Seely
Behavior for unrecognized tags is undefined: http://opensocial-resources.googlecode.com/svn/spec/draft/OpenSocial-Data-Pipelining.xml#rfc.section.12.
My concern is with the tag being in the os: xmlns. That makes it look like a standardized tag, though it isn’t. This will cause support issues for any container that doesn’t implement the tag as the other containers have to explain that “No, it isn’t standardized—[Container X] just implemented the tag and improperly inserted it into the namespace of standardized tags.” These proposed features should have a different namespace until we come to an agreement. For the time being, I’d expect extension tags that containers create to exist in the container namespace. This is what MySpace is doing for tags that we want which aren’t in the spec but are handled by our container.
As an aside, when we come around to standardizing in v.Next, I think we’ll want to consider making flashvars UrlEncoded as part of the default behavior instead of forcing the dev to think about it.
Kevin Brown
Behavior for unrecognized tags is undefined: http://opensocial-resources.googlecode.com/svn/spec/draft/OpenSocial-Data-Pipelining.xml#rfc.section.12.
My concern is with the tag being in the os: xmlns. That makes it look like a standardized tag, though it isn’t. This will cause support issues for any container that doesn’t implement the tag as the other containers have to explain that “No, it isn’t standardized—[Container X] just implemented the tag and improperly inserted it into the namespace of standardized tags.” These proposed features should have a different namespace until we come to an agreement. For the time being, I’d expect extension tags that containers create to exist in the container namespace. This is what MySpace is doing for tags that we want which aren’t in the spec but are handled by our container.
I agree with Scott on this issue. Simply adding an x in front of a tag doesn't help. What if myspace or yahoo or someone who isn't using Shindig did their own implementation of a flash tag, and their "xFlash" didn't match Shindig's? Proper use of namespaces avoids this problem and makes future reconciliation much simpler. Both yahoo and myspace have done this, so I don't see why Shindig should be exempted.
Louis Ryan
Louis Ryan
<div if="${os:existsTag('os:Flash')}">
.. do stuff...
</div>
<div if="${!os:existsTag('os:Flash')}">
.. do other sutff ...
</div>
This should probably move to another thread.
Lev Epshteyn
Louis Ryan
Hi Louis,
How can we show a different version of the flash swf files depending on the version of the Flash player? We have a different build of BuddyPoke for Flash 9 and Flash 10. The Flash 10 version has more functionality. The percentage of users with Flash 10 is not yet high enough for us to simply switch to a single Flash 10 build.
Sounds reasonable. Possible alternatives would be either a substitution pattern in the URL itself e.g. swf="http://www.example.org/myflashv%majorFlashVersion%.swf" or to have different attributes in the tag for each version to support e.g
<os:Flash swf_9="..." swf_10="..." ...>
For a sanitized view, with allownetworking set to internal how can we do things like Flash-based Google Analytic Events? I expect analytics uses different domains, which means it wont work. (And I think Google Analytics might also use the external interface?) Analytics is particularly important for developers. We've started to do branded content (Wolverine on Orkut) and it's important for the client to know how often their pokes are used etc.
I think you would need a separate tag for this, I don't have any objection to supporting one
Will a sanitized canvas view still allow banner ads + virtual payments? Companies like PeanutLabs have *Flex* based payment solutions that can be used on the Canvas view. With a sanitized canvas view and allownetworking=internal I expect this will break their implementation. The canvas view on most apps can contain flash-based banner ads on the same page. How would these be sanitized? Wouldn't banner ads pose a bigger risk than the actual app?
Up to the container, I expect many containers will prefer Caja on canvas views over content sanitization. What is the reason you think allownetworking=internal is breaking their implementation?
Dave Westwood
notes inlined...On Thu, Apr 2, 2009 at 10:30 AM, Dave Westwood <dave.w...@gmail.com> wrote:
Hi Louis,
How can we show a different version of the flash swf files depending on the version of the Flash player? We have a different build of BuddyPoke for Flash 9 and Flash 10. The Flash 10 version has more functionality. The percentage of users with Flash 10 is not yet high enough for us to simply switch to a single Flash 10 build.
Sounds reasonable. Possible alternatives would be either a substitution pattern in the URL itself e.g. swf="http://www.example.org/myflashv%majorFlashVersion%.swf" or to have different attributes in the tag for each version to support e.g
<os:Flash swf_9="..." swf_10="..." ...>
For a sanitized view, with allownetworking set to internal how can we do things like Flash-based Google Analytic Events? I expect analytics uses different domains, which means it wont work. (And I think Google Analytics might also use the external interface?) Analytics is particularly important for developers. We've started to do branded content (Wolverine on Orkut) and it's important for the client to know how often their pokes are used etc.
I think you would need a separate tag for this, I don't have any objection to supporting one
Will a sanitized canvas view still allow banner ads + virtual payments? Companies like PeanutLabs have *Flex* based payment solutions that can be used on the Canvas view. With a sanitized canvas view and allownetworking=internal I expect this will break their implementation. The canvas view on most apps can contain flash-based banner ads on the same page. How would these be sanitized? Wouldn't banner ads pose a bigger risk than the actual app?
Up to the container, I expect many containers will prefer Caja on canvas views over content sanitization. What is the reason you think allownetworking=internal is breaking their implementation?
Adam Winer
The colon comes from the J2EE spec. ":" is for namespacing. "." is
reserved for the possibility of invoking functions on objects, which
is not supported at all in current versions of JavaEE (for good
reason).
-- Adam
Louis Ryan
notes inlined...On Thu, Apr 2, 2009 at 1:33 PM, Louis Ryan <lr...@google.com> wrote:notes inlined...On Thu, Apr 2, 2009 at 10:30 AM, Dave Westwood <dave.w...@gmail.com> wrote:
Hi Louis,
How can we show a different version of the flash swf files depending on the version of the Flash player? We have a different build of BuddyPoke for Flash 9 and Flash 10. The Flash 10 version has more functionality. The percentage of users with Flash 10 is not yet high enough for us to simply switch to a single Flash 10 build.
Sounds reasonable. Possible alternatives would be either a substitution pattern in the URL itself e.g. swf="http://www.example.org/myflashv%majorFlashVersion%.swf" or to have different attributes in the tag for each version to support e.g
<os:Flash swf_9="..." swf_10="..." ...>Either works - I'd lean towards the first version because I expect I'm one of the few that has multiple builds of swf files to take advantage of Flash 10 features. So most developers would just want swf="..."
I tend to agree
For a sanitized view, with allownetworking set to internal how can we do things like Flash-based Google Analytic Events? I expect analytics uses different domains, which means it wont work. (And I think Google Analytics might also use the external interface?) Analytics is particularly important for developers. We've started to do branded content (Wolverine on Orkut) and it's important for the client to know how often their pokes are used etc.
I think you would need a separate tag for this, I don't have any objection to supporting oneThe cool thing about Flash-based Google Analytics is that you don't have to embed the regular analytics javascript. You can create Analytic events directly in Flash, and Flash fires them off. (No js required..) If it was to use a completely separate tag then you're basically preventing OpenSocial apps from using the Flash-based Analytics package. We'd just be using the javascript version via some kind of bridge. Which sort of defeats the cool factor of Google supporting Flash Analytics in the first place.It's also not clear to me how an analytics tag could work with different analytics engines. For example kontagent.
Are you referring to http://gaforflash.googlecode.com? If so it has some support for AS3 based tracking only though use of the "link" feature would be blocked if allownetworking=internal. If flash is to be allowed on sanitized views then a higher level of network access can't be allowed otherwise users are exposed to Phishing attacks through redirection.
Will a sanitized canvas view still allow banner ads + virtual payments? Companies like PeanutLabs have *Flex* based payment solutions that can be used on the Canvas view. With a sanitized canvas view and allownetworking=internal I expect this will break their implementation. The canvas view on most apps can contain flash-based banner ads on the same page. How would these be sanitized? Wouldn't banner ads pose a bigger risk than the actual app?
Up to the container, I expect many containers will prefer Caja on canvas views over content sanitization. What is the reason you think allownetworking=internal is breaking their implementation?allownetworking=internal prevents Flash from redirecting the browser to a new page. Let's say a user selects the option to pay with Paypal. PeanutLabs has their ui in Flex. Clicking on the paypal button would typically redirect the browser to Paypal's site where the user would pay. With allownetworking=internal redirects are not allowed and their payment flow breaks. The app would just sit there.
Again, this would have to be restricted for sanitized views, the app should navigate to the canvas view before doing payments. There is open discussion on support for navigation tags and also to allow flash to connect to a trusted flash app via liveconnect to perform a whitelisted set of operations.
Sean Lin
While trying to get the gadget intellisense to work in Visual Studio, I
think I may have found some problems in the specs at
http://opensocial-resources.googlecode.com/svn/spec/0.8/gadgets/gadgets-exte
nded.xsd
http://opensocial-resources.googlecode.com/svn/spec/0.8/gadgets/gadgets.xsd
Actually, Visual Studio told me so.
1. Line 106: <xs:attribute name="name" type="xs:string" use="optional"/>
should be for the Service element and not the OAuth element (should be after
the inner <xs:sequence> not the outer one).
2. Line 78: It should be <xs:attribute name="rel" use="required"> for the
Link element
Anyway, I've uploaded a fix copy to
http://my6solutions.com/Resources/0.8/gadgets-extended.xsd for those who
want XML intellisense for their gadget for those developing under Visual
Studio. Please correct me if I got the format wrong but it seems to work.
Still working on getting javascript intellisense working at the SAME time.
It can work, along with jquery intellisense, but then XML intellisense will
not work.
Cheers,
Sean
Scott Seely
These functions are interesting, but they either belong in a discussion around v.Next or we delay release of 0.9.
Until then, these should be part of the orkut or shindig object. MySpace does exactly that in 0.7 and the 0.8 container for extensions to the OpenSocial model. So far, this has reduced confusion.
From:
opensocial-an...@googlegroups.com
[mailto:opensocial-an...@googlegroups.com] On Behalf Of Lev
Epshteyn
Sent: Thursday, April 02, 2009 12:20 PM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: PROPOSAL for v.Next :
Opensocial Flash tag
I'm also strongly in favor of the idea of built-in EL functions, as these are very useful for all kinds of formatting (date comes to mind).
Adam Winer
> These functions are interesting, but they either belong in a discussion
> around v.Next or we delay release of 0.9.
features, and this entire thread is about v.Next.
> Until then, these should be part of the orkut or shindig object. MySpace
> does exactly that in 0.7 and the 0.8 container for extensions to the
> OpenSocial model. So far, this has reduced confusion.
exigencies make it more difficult (for users) to do so for XML
namespaces than for Javascript objects, since there's per-namespace
syntactical overhead.
-- Adam
Scott Seely
os: implies that they are part of the spec, which will cause your
supersetting mechanism to lead to confusion in the developer community.
I would prefer to make it clear that the extension is Shindig specific.
Yahoo! and MySpace have been following this pattern and it works quite
well.
> -----Original Message-----
> From: opensocial-an...@googlegroups.com
[mailto:opensocial-and-
> gadget...@googlegroups.com] On Behalf Of Adam Winer
> Sent: Thursday, April 02, 2009 2:08 PM
> To: opensocial-an...@googlegroups.com
> Subject: [opensocial-and-gadgets-spec] Re: PROPOSAL for v.Next :
Opensocial
> Flash tag
>
>
Lane LiaBraaten
Totally agree (with postponing to v.Next). 0.9 doesn't need more
On Fri, Apr 3, 2009 at 7:56 AM, Scott Seely <sSe...@myspace-inc.com> wrote:
> These functions are interesting, but they either belong in a discussion
> around v.Next or we delay release of 0.9.
features, and this entire thread is about v.Next.
Agreed that's the technically correct solution, though some practical
> Until then, these should be part of the orkut or shindig object. MySpace
> does exactly that in 0.7 and the 0.8 container for extensions to the
> OpenSocial model. So far, this has reduced confusion.
exigencies make it more difficult (for users) to do so for XML
namespaces than for Javascript objects, since there's per-namespace
syntactical overhead.
I think a bit of developer pain is okay for extensions/experimental features. If these features become too mainstream before adopting on the spec we'll only shift the problem from having not enough adoption, to having too much.
-Lane
Scott Seely
The discussion then also needs some proposals around what those new functions are. Right now, we have several other metadisucssions that need to happen before agreeing on the tags. It's good that this discussion is bringing this issue to light:
· The EL functions need definitions.
· We have to define how and what is available via EL functions. (“os:” vs. “os.”)
· We need to define a guiding principle for when something is evaluated and added to the DataContext vs. when we create functions and inline the evaluation. Through use of the “requires” attribute, JS could populate items and then allow the OSML to be evaluated. (Yes, I understand the efficiency of server side vs. client side processing—we need to decide when we define a new server side function vs. when we push processing to the client.)
· Some functions, like os:UrlEncode, may not be needed if we properly define the behavior of attributes. We can say “attribute X always UrlEncodes data Y on tag construction.” This may remove the need for some functions altogether.
> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-and-
> gadget...@googlegroups.com] On Behalf Of Adam Winer
> Sent: Friday, April 03, 2009 8:08 AM
Scott Seely
Understand that by pushing features into the os namespace means that containers that do not make that choice will state things like:
“No, [Feature A] isn’t standardized—[Container X] just implemented the tag and improperly inserted it into the namespace of standardized tags.”
This behavior will also hurt the perception of OpenSocial as it will start appearing to be tending towards more of a benevolent dictatorship (ex. Facebook) instead of an open platform.
It also strikes me as poor choice to pursue this path given that MySpace and Yahoo! representatives have made sure to clearly delineate where the differences lie between container-specific features and OpenSocial (experimental/platform specific stuff vs. standard stuff). What would have happened if MySpace had published our existing Album APIs under the OpenSocial namespace and told developers that “we’ll converge later anyhow. Deal with the pain.”? It’s a very real question. We already know that path that MySpace chose, including the benefits we saw from cooperatively collaborating on the final version of the Albums API.
Why would you choose to deprive the group of those benefits for perceived expediency of not needing to change a namespace later?
Louis Ryan
The discussion then also needs some proposals around what those new functions are. Right now, we have several other metadisucssions that need to happen before agreeing on the tags. It's good that this discussion is bringing this issue to light:
· The EL functions need definitions.
· We have to define how and what is available via EL functions. (“os:” vs. “os.”)
· We need to define a guiding principle for when something is evaluated and added to the DataContext vs. when we create functions and inline the evaluation. Through use of the “requires” attribute, JS could populate items and then allow the OSML to be evaluated. (Yes, I understand the efficiency of server side vs. client side processing—we need to decide when we define a new server side function vs. when we push processing to the client.)
· Some functions, like os:UrlEncode, may not be needed if we properly define the behavior of attributes. We can say “attribute X always UrlEncodes data Y on tag construction.” This may remove the need for some functions altogether.