[Live-devel] New, improved "RTSPClient" interface now available

[Ross Finlayson]

>Ross Finlayson <finlayson at live555.com> writes:
>>
>>  How were you intending to use the "client data" value?
>
>Since my application has a number of concurrent RTSP sessions, I
>need to be able to tie responses back to their context.  Without
>a user data pointer, I can think of two options.  The first is to
>keep a global map of RTSPClient object pointers to my data.  I'd
>like to avoid using a global though, because it'll cause some
>difficulty in this application.  The second option is to derive
>from RTSPClient.  This seems like unnecessary complexity though,
>for what I figure is fairly typical use of the new API.

Actually, I don't think that opening more than one RTSP session 
concurrently is a 'typical' use; most applications will probably just 
open one RTSP session at a time (or only one at all).

But in any case, the intention is for there to be a single object 
(pointer) passed to the 'after' function; this object is intended to 
encapsulate all of the state needed by the function.  Having more 
than one object (pointer) is unnecessary.

For the "getNextFrame()" 'after' function, this object (pointer) is 
"clientData", which is a "void*" (but which probably could have been 
a "FramedSource*", because it's always used for "FrameSource" 
subclasses, I think).  For the RTSPClient 'after' function, this 
object (pointer) is a "RTSPClient" itself.

So if the state that you want isn't already encapsulated by the 
existing "RTSPClient" class, then you should subclass it to add the 
state that you want.  (If you need some of the fields/functions in 
the current "RTSPClass" definition changed from "private" to 
"protected", let us know.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/