What will most likely break are in the stream initialization stages, especially SASL and TLS. The current version of HTTP-Binding does not completely address all of the SASL issues (specifically those regarding SASL mechanisms with security layers), and specifically disallows "inband" TLS (since HTTP has its own mechanisms for dealing with SSl/TLS). Otherwise, everything else should be good to go.

I believe the authors of HTTP-Binding are releasing a new revision soon. I would recommend communicating with them, and working out whatever additional issues need to be solved. It may be they've already done so, since these issues are not necessarily unique to Flash.

Also, from an implementation perspective, it should be possible to implement an alternate c2s component that handles HTTP-binding instead of XMPP streams. I know it's possible with jabberd 1.4 (among other server implementations), but I'm not familiar enough with the j2 architecture to properly comment on this.


- LW


dlb wrote:

I don't even know whether this is supported w/ the newest Flash player.
You're right though, it'll try to parse any xml - even invalid xml, hence
the stream element issue.

So perhaps externalizing Flash stream handling is the best approach.
I'm thinking of a simple component that intermediates sessions between a
Flash player and J2 server, conforming their respective streams. So the
component provides J2 w/ a compliant XML stream, and handles all of the null
byte weirdness required by the XMLSocket object.

The question then is which JEPS a/o other features are broken by this
approach ?



_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev

Reply via email to