Matthew Jordan wrote:
<snip>
How so? The current design calls for a public function that
accepts a
const char *key and a const char *value. The key and value are
always
going to be presented to the core as text (inbound SDP), and
typically
will be generated as text (outgoing SDP). Yes, sometimes we may
need to
interpret the values as integers, or floats, or something - but that
will typically be the domain of the resource modules. I'm not sure
storing them as heterogeneous types is all that advantageous.
Two words: Format comparison. The more complex codecs aren't just a
string comparison to know if they are equal, they get turned into a
different type and then a comparison done on that. The amount of
times a format comparison is done throughout the lifetime will also
be greater than that of just interpreting/generating, I wager. The
question is... which one do we want to be fast?
True. OTOH, there is at least one place in the code (and maybe it should
go away? I don't know) outside of the format core that does check to see
if an attribute is set. We will have to 'deal with that', in some form
or fashion.
Yeah, a lot of stuff like that existed in the core because it had codec
specific knowledge. All of that has been moved out so the areas where it
occurs should be minimal. We should have as little codec knowledge in
the core as possible.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
