[Live-devel] Implementing SET_PARAMETER and GET_PARAMETER

[Matt Schuckmann]

Ross Finlayson wrote:
>> Ross you had suggested that I perhaps start by implementing a new 
>> virtual method on RTSPServer for SET_PARAMETER.
>>
>> I looked into doing this in the code and I realized that RTSPServer 
>> doesn't actually handle most of the commands for each session 
>> instance, it's RTSPServer::RTSPClientSession which is a private 
>> member class of RTSPServer.
>> So it looks like I'll have to at the least make RTSPClientSession 
>> protected and provide a virtual constructor method to RTSPServer to 
>> create a new RTSPClientSession (or derived class) from 
>> RTSPServer::incomingRequestHandler1
>>
>> I think I'll then need to virtualize all the handleCmd_* methods (or 
>> at least the GET/SET_PARAMETER ones) in RTSPClientSession so  that 
>> derived  classes  can do there own thing here.
>>
>> Does this sound something like what you were thinking Ross or were 
>> you thinking of something else?
>
> It depends on which object's state you want to update as a result of 
> the "SET_PARAMETER" operation.
>
> If you want to update the state of the "RTSPClientSession" object, 
> then yes, you'd probably need to add a virtual function to 
> "RTSPClientSession".
>
> If, however, you want to update the state of the "RTSPServer" object 
> only, then you could probably do this by writing a generic 
> implementation of "SET_PARAMETER" for "RTSPClientSession" that calls a 
> new virtual function in "fOurServer" ("RTSPServer").
>
> And if you want to update the state of the "ServerMediaSubsession" 
> object, then you would have even more work to do.

Well I want to update an object that represents the state of the session 
as a whole. More specifically a camera object that is producing data for 
multiple streams (at a minimum a video stream and a meta data stream).
Side effects of modifying this object could include modifying the state 
of ServerMediaSubsesssion objects associated with the session (these 
appear to be owned sorta kinda indirectly owned by the RTSPClientSession 
object). I find it a little strange that they are created as a side 
effect of the getStreamParameters() method ( at least I think we are 
talking about the same thing here).

And did I mention there will be multiple of these cameras each with 
there own state and sessions.

It seems like the RTSPClientSessions are the only objects in your 
library that represent each instance of a session as whole, yet they are 
pretty well hidden from the client API (i.e. private to the RTSPServer 
class).
The ServerMediaSession and ServerMediaSubsession objects appear to be 
more factory type classes that describe how to build up the 
RTSPClientSession and it's constituent SourceFramer objects and RTPSink 
objects. So setting a parameter on a ServerMediaSession or a 
ServerMediaSubsession object doesn't really seem appropriate.

What's nice about the RTSPClientSession is they are very general and 
they don't appear to be to muddled with the specifics and I don't want 
to change that.

Unless you can make any more suggestions I'll continue to post as  I 
move forward and let you know how things go.

Thanks
Matt S.