Flash Remoting in Python?

[Dave Brueck]

Flash Remoting is a way for Flash applications to make "native" method
calls in Action Script to a server side program, using the AMF binary
format.

Flash has commercial versions of a Flash Remoting servers. There are
open-source alternatives for php, java, and perl. But alas, no
Python.

Does anyone have any interest in a project like this?

I would be interested in using such a thing, as well as helping out a little.

I've had a need for it in the "normal" use case you mention but also to run
against a local server in order to enable stand-alone (non-browser,
non-network) applications that use Flash for the GUI.

-Dave

 

[Randy]

Flash Remoting is a way for Flash applications to make "native" method
calls in Action Script to a server side program, using the AMF binary
format.

Flash has commercial versions of a Flash Remoting servers. There are
open-source alternatives for php, java, and perl. But alas, no
Python.

Does anyone have any interest in a project like this? It would be
port for the most part; the AMF format is already well known. In
addition, there is a lot of similarities between ActionScript objects
and native Python objects; porting between the two data types would
not be difficult.

Here are some links for info.

http://www.macromedia.com/software/flashremoting/

http://www.simonf.com/flap/ (perl)

http://www.openamf.org/ (java)

http://www.amfphp.org/ (php)

http://www.actionscript.com/archives/00000485.html (discussion about
python flash remoting)

 

[Dave Benjamin]

Does anyone have any interest in a project like this? It would be
port for the most part; the AMF format is already well known. In
addition, there is a lot of similarities between ActionScript objects
and native Python objects; porting between the two data types would
not be difficult.

I think it would be fantastic to have support for this in Python. In fact,
the only thing that's even made me consider using PHP lately is the AMFPHP
library. But be careful! Last time I checked, AMFPHP was not endorsed or
supported by Macromedia. This means a) it might not be legal, especially
with the DMCA and other such intrusions, b) Macromedia could change their
protocol anytime they want, causing everyone to have to reverse-engineer the
changes.

Another way to set up an RPC interface between Flash and Python would be to
use plain old HTTP GET/POST, with either urlencoded key-value pairs or WDDX
as a serialization format. (PyXML supports WDDX, as does PHP, as does Flash
if you Google around for the wddx.as script).

Cheers,
Dave

PS. Still a good idea for a project, though. =)

 

[Dave Benjamin]

Another way to set up an RPC interface between Flash and Python would be to
use plain old HTTP GET/POST, with either urlencoded key-value pairs or WDDX
as a serialization format. (PyXML supports WDDX, as does PHP, as does Flash
if you Google around for the wddx.as script).

Just FYI, you can find the ActionScript WDDX modules here:
http://chattyfig.figleaf.com/

And on the Python side, for starters, try getting this to work:
'<?xml version="1.0"?><!DOCTYPE wddxPacket SYSTEM
"wddx_0090.dtd"><wddxPacket
version="0.9"><header/><data><string>hello</string></data></wddxPacket>'

Dave

 

[Dave Benjamin]

We've been using this XML-RPC library for Flash
http://members.netmadeira.com/killer/xmlrpc/

...and have found that it serves our needs just fine.

Oh, sure, if you want to do it the logical, obvious way...

I will note, however, that Flash's XML parser is slow, and WDDX is more
compact than XML-RPC (although it isn't, in itself, an RPC protocol, unlike
XML-RPC).

Dave

 

[Jordan Krushen]

I will note, however, that Flash's XML parser is slow, and WDDX is more
compact than XML-RPC (although it isn't, in itself, an RPC protocol,
unlike XML-RPC).

God, is it ever slow. I'm working on a remote playlist editor (Flash
talking to Python XML-RPC), and when sending a list of ~1000 entities
across the wire, performance was increased nearly a hundred times simply
by sending one delimited string element instead of 1000 XML elements. Of
course, XML adds quite a bit of bloat, but all the time was consumed in
CPU, not on the wire.

On that note, I've been working on a rewrite of Pedro's ActionScript
XML-RPC library, doing automatic marshalling/unmarshalling, shortening
calls to the following:

rpc = new rpc('http://host/path/')
rpc.send(callbackFunc, 'method', arg1, arg2, arg3...)

instead of the rather verbose and repetitive arg/result formatting which I
found in the original library.

Contact me if you'd like to test it out -- I haven't performed any
regression testing on it yet, but I'm happily using it to pass arrays,
ints, dicts, and strings back and forth.

J.

 

[Andy Dent]

God, is it ever slow.

Are you talking Flash 5 or the MX version, which moved the XML parser
into native code? (and given the strategic nature of this stuff, I
expect MX 2004 to make it even faster.)

I'm using a bit of XML remoting picking up brainwaves from a c++ server
program (and I have my own Python client and server versions as well).
(http://www.ibva.com)

Before anyone gets excited, it's proprietary and the client has already
refused one plea from me to make the comms layer an open source project.

 

[Skip Montanaro]

Jordan> God, is it ever slow. I'm working on a remote playlist editor
Jordan> (Flash talking to Python XML-RPC), and when sending a list of
Jordan> ~1000 entities across the wire, performance was increased nearly
Jordan> a hundred times simply by sending one delimited string element
Jordan> instead of 1000 XML elements. Of course, XML adds quite a bit
Jordan> of bloat, but all the time was consumed in CPU, not on the wire.

Have you tried installing sgmlop, which pushes most of the XML parsing into
C?

http://www.pythonware.com/products/xml/sgmlop.htm

Skip

 

[Jordan Krushen]

Are you talking Flash 5 or the MX version, which moved the XML parser
into native code? (and given the strategic nature of this stuff, I
expect MX 2004 to make it even faster.)

MX. Granted, there's an XML-RPC library on top of it, but I stripped that
down quite a bit as well. Let's face it.. XML just adds horrible bloat,
both space- and CPU-wise for large lists of small items. Besides, I
easily solved the problem by sending one large delimited string instead of
an array of small strings.

I'm using a bit of XML remoting picking up brainwaves from a c++ server
program (and I have my own Python client and server versions as well).
(http://www.ibva.com)

Thanks for the link! I've always wondered where stuff like this hid on
the net.

Before anyone gets excited, it's proprietary and the client has already
refused one plea from me to make the comms layer an open source project.

I'm using standard XML-RPC for the moment, 'cause it's easy -- especially
on the Python side, and getting easier on the Flash side, as I rewrite
this library.

J.

 

[Jordan Krushen]

Jordan> God, is it ever slow. I'm working on a remote playlist editor
Jordan> (Flash talking to Python XML-RPC), and when sending a list of
Jordan> ~1000 entities across the wire, performance was increased nearly
Jordan> a hundred times simply by sending one delimited string element
Jordan> instead of 1000 XML elements. Of course, XML adds quite a bit
Jordan> of bloat, but all the time was consumed in CPU, not on the wire.

Have you tried installing sgmlop, which pushes most of the XML parsing
into C?

It's the Flash side that's slow, not the Python one Python merrily
spits out an array of 1000 small items into XML-RPC in way under a
second. Unmarshalling it on the other end in Flash took noticeably
longer. I've taken to stripping the Flash XML-RPC library down to its
minimum, but it's still rather slow. The Python lib is more complete, and
written in Python, but it's still quite a bit faster than Flash.

J.