<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/2585/">https://reviewboard.asterisk.org/r/2585/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Joshua Colp.</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This change adds two new things:
1. Extended fields
Extended fields are fields specifically marked as extending an object. This means they are not held to the same type safety as normal fields and simply exist as a list that can be queried. The pro of this is that the object that is extended does *not* have to be modified when other modules need to attach data to it. The con of this is that type safety must be enforced at the time of consumption by the user of the extended field. A test is also provided which confirms functionality.
2. Opaque sorcery data
Previously sorcery data was placed directly in the structure definition for objects. This had the consequence of requiring any modules using the structures to be recompiled if the sorcery structure changed. The change attached adds a generic sorcery object allocation function which allocates enough room for an internal opaque structure. This has the benefits that modules do not need to be recompiled if internal details change and it also allows additional data to be attached to sorcery objects and properly deallocated when the object is destroyed.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ran unit tests, confirmed all happy. Used Gulp functionality and confirmed it is also happy.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/include/asterisk/sorcery.h <span style="color: grey">(390335)</span></li>
<li>/trunk/main/sorcery.c <span style="color: grey">(390335)</span></li>
<li>/trunk/res/res_sip/config_auth.c <span style="color: grey">(390335)</span></li>
<li>/trunk/res/res_sip/config_domain_aliases.c <span style="color: grey">(390335)</span></li>
<li>/trunk/res/res_sip/config_transport.c <span style="color: grey">(390335)</span></li>
<li>/trunk/res/res_sip/location.c <span style="color: grey">(390335)</span></li>
<li>/trunk/res/res_sip/sip_configuration.c <span style="color: grey">(390335)</span></li>
<li>/trunk/tests/test_sorcery.c <span style="color: grey">(390335)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2585/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>