[jdev] Flash Proxy (was: Jabberd2, Flash Client...)

[dlb]

another advantage of a protocol handshake
is that it can be used to convey session, security, and
application-specific details relevant to a given
Flash client implementation.

For instance, an application might want to transpose
its security policy to the proxy session. It might need to
connect on an alternative port due to firewall issues. And
the Flash player might then need to load a 'shim'.


----- Original Message -----
From: "Richard Dobson" <richard at dobson-i.net>
To: "Jabber software development list" <jdev at jabber.org>
Sent: Thursday, April 15, 2004 4:29 AM
Subject: Re: [jdev] Flash Proxy (was: Jabberd2, Flash Client...)


> > Richard - thanks for the very thorough outline. Once the Flash client is
> > done with initial negotiations and reverts to XMPP, does the proxy just
> > sort of become a "dumb router" in the sense that it merely strips the
> > zero-byte of the incoming data (from Flash) and sends it on it's merry
> > way? I guess my question is why the need to develop a proxy control
> > protocol when we could just use XMPP?
>
> Because you cant just use standard Jabber/XMPP. The <stream:stream> does
not
> work (you have shown that you can send it, but I would expect when you get
> the returning <stream:stream> it would blow up since flash is expecting a
> complete xml chunk, hence why you cant just use standard Jabber/XMPP),
also
> you cant just use Jabber/XMPP because it does not contain any of the
needed
> control commands such as the command I detailed at step 2 that tells the
> proxy to connect to the server, also the login stuff at step 4 could be
done
> with normal Jabber/XMPP SASL but IMO its far better to move the more
complex
> processing stuff into the proxy such as handling all the SASL stuff etc
> rather than in the flash, also when I say reverts back to normal
Jabber/XMPP
> all it means is it will pass the <presence> <iq> and <message> stanza's
> along essentially untouched, although if you do get any more
<stream:stream>
> level stanza's these will be handled by the proxy and converted into the
> proxy control protocol (the proxy control protocol is basically just a
layer
> to replace the <stream:stream> level stanza's, and contains the
> functionaility necessary to complete its proxy functionality).
>
> There is nothing stopping us from making the protocol I described looking
> more Jabber/XMPP'ish if needed as all I was trying to do was illustrate in
a
> simple way how I was thinking it would work. Also since we cant use
standard
> Jabber/XMPP we shouldnt just be hacking the existing parts that wont work
> IMO so they do, that just makes things messy later on, IMO its far better
to
> start with a clean slate as it were and simply replace the part that does
> not work (<stream:stream>) with something that does work and is as simple
as
> possible, just like happens in JEP-0124 (the <stream:stream> aspect has
been
> removed and replaced with its own more appropriate protocol).
>
> Richard
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> https://jabberstudio.org/mailman/listinfo/jdev