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

[Doug Porter]

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.

An alternative to having a per-request user data pointer, is
providing the ability to keep one on the RTSPClient object.  That
at least keeps the clutter down on method signatures.

With regard to passing the CSeq back to the handler function,
that seems reasonable.  It doesn't solve the problem I'm trying
to address, but simplify work for some people.  It's worth noting
though that RTSP responses have to come in the same order as
requests, so I don't know that passing the CSeq to the response
handler will be a great boon.


> The URL is now passed as a parameter to
> "RTSPClient::createNew()".

Ah, thanks.  I had missed the new version of createNew().


I appreciate your help,
-- 
dsp