[rtmpdump] [PATCH] AMF Object Callback

[Chris Larsen]

Thanks Adam, sorry for the delay, tied up with work.

>> I don't know if the response needs to be a union since we're only creating a callback for AMF data and not other types, but if ya'll want to use a union that's cool.

> The idea is simply because if we wanted to have a callback that returned something other than AMF, we'd have to make new callback prototype. By using a 
> RTMPCallbackResponse struct, we can hold whatever we may need in the future with the same prototype. I think this is the biggest difference between our 
> two patches.

I put the union back into my patch and test it out so it works and makes sense for a more generic callback as opposed to just AMF. 

>> It is nice to have the ability for the callback to return a number of different responses so I implemented Howard's types and added some logging lines to let the user know exactly what the callback did within libRTMP.

>I'm not really sure about the difference between the two, sounds more like a problem on agreeing what a "default" success should actually do and really just a > name change. I'm not sure about doing the check of the status code again within HandleInvoke and HandleMetadata just for logging but I guess it's ok.

I left this as is for now but we can change it if necessary

>> This version also blocks duplicate callback subscriptions. It will also execute all callbacks until one callback tells it to abort. That way you can have a logging callback that watches all messages and then a separate one that takes action on a certain type.

> I don't understand what you mean here extactly, wasn't this possible in my first patch?

Sorry, yeah, your version did to. 

Let me know what else needs to be changed and we'll see what Howard says. Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amf_callback_v8.patch
Type: application/octet-stream
Size: 8653 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20110822/ed3e56ac/attachment.obj>