[Live-devel] Which kind of code you would accept?

[Ross Finlayson]

>On Wednesday 28 July 2010 08:04:10 Ross Finlayson wrote:
>  > Specifically, looking at your suggestions:
>>  >  - C++ standard library string or custom string class (which one if any)
>>  >  - custom command line options parser class
>>
>>  No, ...
>>  because they don't fix bugs, nor do they improve (or even really
>>  change) the code's API
>
>In fact use of std::string instead of char* is both change and improvement of
>API. User of library would not need to worry about delete [].

In the future I'll definitely consider switching to using 
"std::string" if/when I become sure that it is available - and 
efficient - for *all* potential users of our code.  Right now, 
though, I'm not sure of this.


>  > Ditto for 'standard' C++ libraries, which might also make
>>  applications too large for some embedded systems.
>
>Standard C++ libraries could sometimes become huge, but there are 
>techniques to keep final binaries small.

That's too vague.  I really want to make sure that this code remains 
useful, and usable, for people who are developing small embedded 
systems.


But my basic point remains: If people are using the code properly, 
then the kinds of changes that you are proposing are just not 
important, because they add little new functionality.  So please stop 
harping on about this.

The more of my time that is wasted dealing with unimportant questions 
like this is time that I don't get to spend on adding important new 
functionality that will really help people, like, for example:
1/ A new simple RTSP client demo application ("testRTSPClient") that 
will give developers a much clearer picture of how to use 
"RTSPClient" (as opposed to the code for the "openRTSP" application, 
which is complex and has lots of 'bells and whistles' that are 
unneeded by most developers).
2/ New test programs (and 'framer' classes) for H.264 video (because 
many people seem to be having lots of trouble sending (especially) 
and receiving H.264 video.

Both of these things (and a lot more - e.g., stuff that will 
eventually lead to support for IPv6) is all on the drawing board, but 
keeps getting delayed by distractions...
-- 

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