I am not sure if making some functions virtual or separating construction from setting is best. My case may be too edge.
I haven't gotten far enough to give you a list, that's for sure. But if the callback could use a void* for the first arg, then I can wrap the client in a myClient class, pass it's pointer and access the internal pointer to the RTSPClient. That is a different form of subclassing for sure, but it helps callbacks. For me the requiring of info on ctor doesn't happen to fit my existing interface. (not all clients in my code are live555 RTSP clients) In this legacy case, the url is built dynamically depending on the model of the encoder. I suppose it could be redone, but that would change an interface and all the classes that inherit from and use it. //thinking out loud.. What if you created an abstract interface class for c++ users. They inherit from this class an implement the callback functions. It would have c-style call wrappers kinda like the whole afterGettingFrame and afterGettingFrame1 setup. You could grant access by befriending the interface? From: [email protected] [mailto:[email protected]] On Behalf Of Ross Finlayson Sent: Saturday, November 26, 2011 2:57 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] problems moving to asynchronous rtsp interface >> I realized that and am working on the subclass from RTSPClient idea. Because >> there is a LOT of other instance data, just like in the openRTSP example, >> thre is a LOT of global information. But I am finding that the RTSPClient >> was not really designed to be subclassed. The gotcha I have now is, although >> it does nothing but set values in it's constructor, I cannot instanitiate my >> subclass without an initializer for the RTSPClient base class, but then I >> cannot call setBaseURL() for example, later when I know all the info. I'm not sure I understand this. Your subclass's constructor will, of course, call the "RTSPClient" constructor before initializing its own variables. One of the parameters to the "RTSPClient" constructor is a "rtsp://" URL, which the "RTSPClient" constructor uses, internally, by calling "setBaseURL()" to save its value. Are you saying that you want to call "setBaseURL()" from your subclass, to set a *different* "rtsp://" URL - one that you want to build inside your subclass constructor (rather than one that you know in advance and are giving to the subclass constructor, as is the case for "RTSPClient")? If that's the case, then yes, "setBaseURL()" will need to be protected, rather than private (and then your subclass constructor can just pass NULL as the "rtspURL" parameter to the "RTSPClient" constructor, before it creates the real URL). So, would you like me to make "setBaseURL()" protected rather than private? Any other member functions or variables as well? (This is what this mailing list is for :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
