[Standards] Flash binding for Jingle

Matt Tucker matt at jivesoftware.com
Wed Jan 31 22:51:46 UTC 2007


I agree with all your points and definitely support making the XEP
something that the XSF officially supports.

To address Michael Vaner's comment -- we'll do our best to support
server-side interop between Jingle transports in Wildfire, but I'm not
sure how possible it will be yet.

Next step: I'll help Dele submit this as a proto-XEP so that the council
can take more official action on it.


> -----Original Message-----
> From: standards-bounces at xmpp.org 
> [mailto:standards-bounces at xmpp.org] On Behalf Of Ian Paterson
> Sent: Wednesday, January 31, 2007 11:21 AM
> To: XMPP Extension Discussion List
> Subject: Re: [Standards] Flash binding for Jingle
> Peter Saint-Andre wrote:
> > Matt Tucker wrote:
> >
> >>> So, this is some transport that is easier to write in 
> flash? I guess 
> >>> I noticed the protocol being proprietary. Does it mean 
> every client 
> >>> that wants to talk with flash client needs to buy it from adobe?
> >>
> >> Yes, unfortunately, Flash is a proprietary protocol. 
> However, see my 
> >> last email. There's now a viable open source Flash server 
> >> implementation, which suddenly makes things pretty interesting. 
> >> Having Adobe as a commercial solution is also valuable.
> >
> > Naturally I can't say that I'm excited about proprietary protocols. 
> > It's true that Jingle was designed to be modular, so that 
> we can plug 
> > in various transports and content types. However, I'm not sure it's 
> > appropriate for the XSF itself to publish specs for 
> interacting with 
> > proprietary protocols. Would we publish a XEP for sending 
> > RTF-formatted messages or collaboratively editing MS Office 
> files? Not 
> > sure. Perhaps the right place to publish a spec for the 
> Jingle Flash 
> > transport is on Adobe's site.
> >
> >> Either way, I'm pretty excited about the XEP for a few reasons:
> >>
> >>  * Jingle needs a kick in the pants and a bit of sexiness. Open 
> >> standards voice audio in web pages is sexy.
> >>  * There are rumors of Flash support for SIP from Adobe:
> >>
> >> 
> http://blog.tmcnet.com/blog/tom-keating/voip/adobe-flash-goes-voip.as
> >> p
> >>
> >>  I'd much rather see XMPP be the way that VOIP in Flash gets done.
> >
> > I like the idea of Jingle over Flash, but I'm not sure if 
> it's right 
> > for the spec to be published in the XSF's standards process.
> I agree it is not normally appropriate for the XSF to publish 
> specs for interacting with proprietary protocols. However 
> this case just might be an exception.
> While there are plenty of open alternatives to MS Office 
> files, Flash is still the _only_ way that an XMPP Web client 
> (installed on a typical public website) can do Jingle without 
> asking most users to install a plugin. Furthermore, AFAIK, 
> there is nothing open and ubiquitous coming over the horizon.
> Since 2002, VoIP for Web clients has meant Flash, and that's 
> not going to change anytime soon, quite the opposite. IMHO 
> the emergence of the
> Red5 open source RTMP server could be the first of two 
> crucial steps towards an explosion of Flash-based VoIP 
> clients (the second being the standards-based peer-to-peer 
> audio/video streaming that is likely to be built into the 
> next major release of Flash Player).
> If we can persuade Web (Flash) developers to adopt Jingle 
> now, then hopefully they will continue to use it (XMPP is 
> exceptionally Web-developer friendly after all), and Flash 
> support will then prove to be one of the important motivators 
> towards the widespread adoption of Jingle. Dele's XEP is a 
> key step towards that goal.
> So I think we should help Dele (at least semi-officially). 
> For examples, the XEP could benefit from the Standards-JIG 
> process, and it should be published where XMPP developers 
> will stumble across it. i.e. The XSF's Jingle XEPs should at 
> least link to it, even if the XSF doesn't officially publish it.
> The XSF Council will probably discuss this case on Feb 14th, 
> so any feedback on this list will help motivate that 
> discussion. Do feel free to flame me about the evils of 
> supporting proprietary protocols.
> - Ian

More information about the Standards mailing list