Re: [Gnash-commit] /srv/bzr/gnash/trunk r11136: migrated rtmp netstream and netconnect classes from rsavoye's local branch and fixed various test cases in misc-ming.all

[Rob Savoye]

On 06/17/09 08:23, Benjamin Wolsey wrote:

> For instance, the older code offers a connection handler that allows you
> to open either an http connection or an rtmp connection. That means
> libnet can create either an http client or an rtmp client as necessary
> for each connection, instead of both as it does now, which saves
> resources and makes controlling both types of connection much simpler.

  The current code from the RTMP branch also supports HTTP and RTMP, so 
I fail to see the difference. Instantiating the HTTP or RTMP classes 
could be done a little more dynamically, if that's what you mean. But 
that's a minor issue. I'm more concerned right now with whether or not 
RTMP, RTMPT, etc... work.

> The connection handlers also would allow connections to be threaded (or
> not, whatever is better) while not messing up the AS execution order.

  The code from the branch was also designed to be multi-threaded, the 
problem was the Gnash VM isn't thread safe. The original code also has 
serious performance issues, mostly because of how it handles returning 
the data from an RTMP message to the VM.

> And as a design principle, it keeps NetConnection at arm's length from
> any particular network backend, so any future refactoring isn't as
> disruptive.

  We will be using libnet for a long time, so I don't forsee any major 
refactoring after this current one. After this stabalizes, I was going 
to add RTMP streaming support to NetStream next, after which point we'll 
drop curl usage entirely.

        - rob -