[JDEV] RFC: cross-domain Flash support
dlb
civintel at comcast.net
Mon Oct 21 15:09:06 CDT 2002
Jabberd , JCP , and JabCast support TCP connections from the Macromedia
Flash player.
Flash is a relatively pervasive web medium and provides an effective
mechanism for integrating jabber within web applications and other web based
resources. Developers can access the jabber stream from a web page through
Flash using its scripting interface. In this way you can integrate jabber to
a web app. using conventional web development methods.
here's the problem ...
Flash applications are run in a sandbox , much like a java applet , and
therefore Flash based jabber clients can only connect to the domain hosting
the client's shockwave file ( SWF ). This imposes some significant
impediments on jabber integrated web apps that rely on Flash - users can't
log-in to their primary accounts if these reside w/ a foreign server , new
accounts have to be established w/ each individual domain hosting a Flash
Jabber application. The application's host must run a jabber server in their
domain , or implement a proxy that intermediates the session.
I've developed a simple way to enable web based Flash Jabber apps to connect
to foreign domains. This requires that a small Flash file , an SWF, be
hosted by whichever domain the user is attempting to log-in to . This SWF
hosts the socket instance used for the connection. I'm interested in
getting some feedback on how we can standardize support for hosting this
file among jabber installations, so that the user doesn't need to know the
specific location of the file within each domain. Pervasive support for
cross domain connections from Flash applications could be leveraged to make
jabber a dominant solution for the adaptation of messaging and presence
within web applications.
If you're interested in this area pls read the following...
____________________
Standardizing a Flash 'shim'
There's a way to circumvent the Flash sandbox by having the Flash client
load a 'shim' from the foreign domain. The shim is a small SWF that
establishes the socket instance used by the Flash client when connecting to
the foreign server. For instance if I were to download a Flash webclient
from www.hellokitty.com and want to connect to my account at jabber.org ,
the client can load a shim from jabber.org to establish the connection. The
shim would need to be retrieved via http.
Standardization of this mechanism could simply involve hosting the shim in a
commonly agreed upon location - eg. http://jabber.org/flash/shim.swf ,
across all participating jabber hosts.
There a few significant advantages to standardization.
The ability to message , maintain presence , manage your roster, and access
other jabber resources, through a common JID across different web domains
The establishment of a common identity ( JID ) for web based interactions
using the jabber protocol. This then could be leveraged towards the
development of PIM-type features that could be applied to a range of web
apps.
This facilitates inter-domain web based collaboration and 'universal' jabber
based services.
significantly reduces barriers to the adoption of jabber within web
applications - these could rely on third party hosts.
____There are several issues that would need to be addressed______
including ...
where / how is the shim hosted within the Jabber domain. Do most hosts run
an HTTP server as well , does the jabberd distro include an http server that
I'm not aware of ?
what are people's security concerns and what are acceptable ways of dealing
with these.
how can hosts prevent sites from exploiting their capacity
opportunistically.
how can this effort enhance other jabber-web integration projects like
DotGnu.
____________
Regards;
David Beard ~ FML developer and maintainer
More information about the JDev
mailing list