I'm working on rtsp performance test tool and I
will produce some code which I'd like to contribute. I know your strict
opinion on patches, so I'd like to know in advance if you would accept:
I don't have any definitive rules about what sort of patches I
accept. However, the patches that I'm most likely to accept are:
1/ Bugfixes, and
2/ Changes that make it easier for developers to extend the supplied
code via subclassing, rather than forcing them to modify the supplied
code.
The kind of patches that I'm least likely to accept are those that
make changes throughout the code (in several files), especially if
they are mostly cosmetic in nature.
A problem we've had recently is that some people have apparently made
little effort to try to leave the supplied code unchanged. Instead
(perhaps because of laziness, or perhaps because of a lack of
understanding of how C++ subclassing works; I'm not sure), they have
charged ahead and merged the supplied code with their own application
code, making widespread changes to the supplied code. They then want
me to adopt these changes without question (e.g., so that they can
more easily upgrade to new versions of the code), and then throw a
hissy fit if I refuse to do so.
I'm sorry, but that's not the way the code is supposed to be used.
If people have misused the code this way, then I'm not going to
'reward' them by adopting their modifications without question.
Specifically, looking at your suggestions:
- common Linked List class (linked lists are already used on several places)
- custom templates (for example function max() )
- C++ standard library string or custom string class (which one if any)
- custom command line options parser class
No, I won't be adopting any of these (at least, not anytime soon),
because they don't fix bugs, nor do they improve (or even really
change) the code's API - only its implementation, which developers
shouldn't really be caring about very much (as long as it works).
(I'm also a bit wary about using some of the newer C++ features (such
as templates), because some people's compilers might not support
them. Ditto for 'standard' C++ libraries, which might also make
applications too large for some embedded systems. I like to be a bit
conservative about which features of C++ I use for the "LIVE555
Streaming Media" libraries.)
The things that you mention might be nice for *your* application
code, but they don't have to be also applied to our library code - if
you are using it correctly.
In addition I found current RTSPClient design difficult for my
specific needs. So
I plan to write other implementation.
Go ahead. Of course, you should give your new class a new name - not
"RTSPClient".
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
