History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-2554
Type: Improvement Improvement
Status: Open Open
Priority: P2 P2
Assignee: Don Hopkins
Reporter: Sebastian Wagner
Votes: 3
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
OpenLaszlo

RTMPConnection - how to handle *server-side-calls*

Created: 24/Aug/06 05:47 PM   Updated: 31/Oct/07 08:35 AM
Component/s: Extensions - Streaming Audio / Video
Affects Version/s: 3.3.3
Fix Version/s: Future

Time Tracking:
Not Specified

File Attachments: 1. File rtmpconnection.lzx (12 kb)
2. File rtmpconnection.lzx (10 kb)


Severity: Minor
Runtime: N/A
Fix in hand: False


 Description  « Hide
There is still a issue to solve with the rtmpconnection:

How to handle server-side calls which are not mapped by the client.

Simple szenario

The server (I'm using Red5) broadcast a message to the client *without* invoking by the client.

atm the rtmpconnection-class only hanldes server-side calls if they have been invoked by the client.

for example:

<netremotecall name="getList" funcname="demoService.getListOfAvailableFLVs">
<method name="onResult" args="value">
</method>
</netremotecall>

This will work! the server side response will be mapped to the *onResult* method (btw should this be changed to the new *handler* syntax of OpenLaszlo cause it may be confusing to use a *on[whatever]* function with the *old* method syntax instead of the *handler* syntax)

*but*

if the server broadcasts messages *without* invoking it by the client atm they can only by catch by the following syntax:

            // This is the way a function is called by the remote Interface has
            // to be implemented ...
            /**
            this._nc.setId = function(id){
                _root.Debug.write("########## Method called by rtmp Server");
                _root.Debug.write("---------------> id: ",id);
            }
            **/

this should by removed by a more clear syntax which is more like OpenLaszlo does handle methods/handlers.

The problem so far is:

How to catch server side calls?

What i think about is, or what would be very helpfull is a message in the debugger:
*ERROR: rtmp-connection calls method *whatever* which is not mapped to a function*

This is quite important issues cause is enabled asynchron client-server communication which is very common/usefull is Application like chats/instan messangers/mail-clients/games

The *NetConnection Debugger* does it with the *__resolve* function (which is I think a internal FlashPlayer function you can find some docs on MM-Livedocs.

So there are two things to solve:
1) get an event that is invoked if server calls a method assynchron
2) map server-side calls to method (could be done quite easily by register avery *netremotecall* to the rtmpconnection-Object)
3) if there is no function mapped write an error to the Debug

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Sebastian Wagner - 21/Sep/06 04:42 PM
The attached file handles calls invoke from server side

so that could be a fix for problem 1) and 2)
I don't know about server callbacks.
It works with red5 (0.5 + 0.6)

to Problem 4) *what if there is no funtion mapped to a server side call*
Red5 will throw a debug message that the function can't be found, is FMS doing the same?


Sarah Allen - 21/Nov/06 06:22 PM
do you have a test file for this? without one I hestitate to check this in... ideally this would be a simple test file that just illustrates this one thing

Sebastian Wagner - 21/Nov/06 11:48 PM
to test it you have to invoke some methods from server side.
I can attach a Red5 Servlet which is doing or link to a working Application who is using it.

You can see a working demo here:
http://www.webbase-design.de/webrooms/

There are a lot of calls from Server Side in this application you can see in the debugging window.

Sebastian Wagner - 12/Apr/07 03:18 AM
this is already a slightly modified version of the same file
there is a new param *remotecontext* sothat you can implement a netremotecall outside of the *netconnection* brackets.