Posted on Saturday 30 April 2005
Many Remoting developpers would appreciate being able to send all of their remoting calls through RTMP, the protocol used by FlashComm server. The advantage would be obvious: virtually no lag when sending calls to and from Remoting, because the connection is already made. Now the remarkable thing about Remoting and FlashComm is that at a very low level they are essentially the same. What you say? Well, for example, the class definition for mx.remoting.Connection is:
class mx.remoting.Connection extends NetConnection
Others have reported that RTMP uses the very same kind of AMF data as a messenger between FlashComm server and the client. There still remains a gap between Remoting and FlashComm however as RTMP cuts the fat out of TCP/IP (hence the need for an actual new protocol).
ColdFusion 7 now includes event gateways, which allows ColdFusion to interact with other messenging protocols. Well RTMP is just such a protocol. That would mean that anyone with Java writing skills (ie: not me) and a lot of experience with AMF (ie: me) would be able to write an RTMP event gateway for ColdFusion. This possibility is quite tantalizing indeed, and I believe that someone could basically plug into the event gateway architecture, create dummy clients, interact through RTMP and consume CFCs. This would require of course recreating another AMF serializer/deserializer, but in fact the code is already laid down in OpenAMF, and in fact practically copy-pasted from Wolfgang's original one in AMFPHP.
So what I envision is simply an event gateway that uses RTMP as a drop-in replacement to TCP/IP for Remoting communication. Given CFCs adapted for Remoting use, all that one would do to the faster, better RTMP gateway would be to:
- Change the gateway url from http://.../gateway to rtmp://.../gateway
- Modify the function isHttpUrl in mx.remoting.NetServices to allow rtmp communication
- Profit!
Now I am no expert in ColdFusion (in fact I've never used the thing outside of comparing AMF output to AMFPHP for debugging purposes) so I may be completely wrong in this feasibility. Nevertheless, I think this is an interesting possibility, and I will certainly give my hats off to anyone who has the skills to actually try it. Once one can do Remoting calls using this gateway, of course one may envision stuff like playing streaming video and audio, multi-user session-based handling, and other tantalizing EULA-breaking stuff ;)
