<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/2578/">https://reviewboard.asterisk.org/r/2578/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On June 1st, 2013, 12:10 a.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://reviewboard.asterisk.org/r/2578/diff/2/?file=38821#file38821line64" style="color: black; font-weight: bold; text-decoration: underline;">/trunk/bridges/bridge_builtin_features.c</a>
<span style="font-weight: normal;">
(Diff revision 2)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">ASTERISK_FILE_VERSION(__FILE__, "$Revision$")</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">64</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="n">RAII_VAR</span><span class="p">(</span><span class="k">struct</span> <span class="n">ast_features_xfer_config</span> <span class="o">*</span><span class="p">,</span> <span class="n">xfer_cfg</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">,</span> <span class="n">ao2_cleanup</span><span class="p">);</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">RAII_VAR is overkill here since all you want to get is digit_timeout. Also you can defer getting the digit_timeout until you need it in the one location.</pre>
</blockquote>
<p>On June 3rd, 2013, 2:48 p.m. UTC, <b>Mark Michelson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">As the API is written, you don't have a choice other than to grab the xfer_config. There are not accessor functions for each individual option.
I felt that grabbing the xfer_config locally in this function was better than passing just the digit timeout into the function as a parameter because this would scale better if other transfer options became relevant in this function.</pre>
</blockquote>
<p>On June 3rd, 2013, 4:24 p.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The reason RAII_VAR is overkill here is because you are only getting an integer out of the xfer_cfg. You don't need to keep a reference to xfer_cfg after that is done.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I'm going to respectfully disagree with this line of reasoning.
I tend to use RAII_VAR whenever it may be applicable, even if the reference continues to exist after my last access to it. The two main reasons are that it makes reference counting easier to get correct, and it makes it easier for refcounting to stay correct when code changes. To me, the automatic destruction behavior of RAII_VAR is something that makes it preferable to use in any situation over manual destruction. Changing away from using RAII_VAR seems like a big step backwards.</pre>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On June 1st, 2013, 12:10 a.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://reviewboard.asterisk.org/r/2578/diff/2/?file=38835#file38835line341" style="color: black; font-weight: bold; text-decoration: underline;">/trunk/main/features_config.c</a>
<span style="font-weight: normal;">
(Diff revision 2)
</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">341</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="k">static</span> <span class="k">struct</span> <span class="n">aco_type</span> <span class="n">featuregroup_option</span> <span class="o">=</span> <span class="p">{</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">342</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">type</span> <span class="o">=</span> <span class="n">ACO_ITEM</span><span class="p">,</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">343</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">name</span> <span class="o">=</span> <span class="s">"featuregroup"</span><span class="p">,</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">344</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">category_match</span> <span class="o">=</span> <span class="n">ACO_BLACKLIST</span><span class="p">,</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">345</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">category</span> <span class="o">=</span> <span class="s">"^(general|featuremap|applicationmap)$"</span><span class="p">,</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">346</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">item_offset</span> <span class="o">=</span> <span class="n">offsetof</span><span class="p">(</span><span class="k">struct</span> <span class="n">features_config</span><span class="p">,</span> <span class="n">featuregroups</span><span class="p">),</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">347</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">item_alloc</span> <span class="o">=</span> <span class="n">featuregroup_alloc</span><span class="p">,</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">348</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">.</span><span class="n">item_find</span> <span class="o">=</span> <span class="n">featuregroup_find</span><span class="p">,</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">349</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="p">};</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Aren't you supposed to also parse the features.conf [parkinglot_*] sections?</pre>
</blockquote>
<p>On June 3rd, 2013, 2:48 p.m. UTC, <b>Mark Michelson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">That wasn't part of my task. Parking lot configuration currently lives in res_parking.conf. Parking lot configuration could be migrated back over to features.conf and mixed in with the rest of the features.conf configuration with some effort though.</pre>
</blockquote>
<p>On June 3rd, 2013, 4:24 p.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Parking lot configuration was previously in features.conf. For features.conf to remain backwards compatible, you should at least parse those options and not give errors about "unknown" options.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Okay, I see what you're saying now. If someone has a [parkinglot_foo] context, we'll try to parse it as a featuregroup right now. We should instead print an error and abort loading since the configuration will not work as expected.</pre>
<br />
<p>- Mark</p>
<br />
<p>On May 30th, 2013, 6:46 p.m. UTC, Mark Michelson wrote:</p>
<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, jrose and rmudgett.</div>
<div>By Mark Michelson.</div>
<p style="color: grey;"><i>Updated May 30, 2013, 6:46 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21542">ASTERISK-21542</a>
</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 separates features configuration out of features.c into a separate features_config.c file. In addition, a features_config.h file has been added as a means of getting configured values. The configuration changes are as follows:
* Configuration for features uses the config framework now.
* The FEATURE and FEATUREMAP functions use the same handlers as the configuration. Therefore, any configuration item available in the config file is also available for the FEATURE and FEATUREMAP functions
* Because the FEATURE and FEATUREMAP functions are more complete, feature configuration retrieval is done per channel rather than globally. Global configuration can be retrieved, but this is a rare occurrence.
* The CLI command to show feature configuration has been moved into the features_config.c file as well
* Three new options for attended transfers were added: atxfercomplete, atxferabort, and atxferthreeway. Now the key combinations for completing, aborting, and conferencing an attended transfer are no longer hard coded.
Since feature configuration is handled differently than it used to be, it meant that several items from features.h and features.c could be removed altogether:
* All functions having to do with configuration parsing have been removed from features.c. This includes functions that were used to modify the dialplan due to parking options being parsed.
* Functions that retrieved call features have been removed. This includes the removal of ast_call_feature, its associated locks, the builtin_features array, and functions used to find dynamic features.
The result of removing some of the above meant that there was quite a bit of dead code in features.c. However, I did not remove this code and instead opted to comment it out for several reasons. The following bits have been commented out rather than being removed.
* All builtin feature operations in features.c have been commented out. These items had already been "dead" for a while, but now that nothing references them, they had to be commented out in order to compile with devmode enabled. I left these commented out since there are currently tasks to make the builtin features feature-complete. Leaving the old code around as an example is not a bad thing.
* The unit tests in features.c have been commented out. The new parking code currently does not have unit tests, so keeping the old unit tests around but commented out allows for them to be used as a guide when writing new tests.
There was a tangential change as well: an AST_FEATURES_DTMF_MASK constant was added that can be used to tell if a builtin feature requires DTMF. This was necessary for setting up bridge features since the ast_call_feature structure was removed.
Things I'm looking for in this review:
* Are there items in features.c that I have commented out that should just plain be removed instead?
* Are there any items in features.c that I removed that should not have been?</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;">Tested configuration parsing. Ensured that general features, featuremap items, applicationmap items, and featuregroups were set and retrievable properly.
Tested that the FEATURE and FEATUREMAP dialplan functions overrode the global configuration in features.conf
Tested that items in the featuremap and applicationmap could be triggered mid-call. This includes the new attended transfer options.</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/apps/app_dial.c <span style="color: grey">(390144)</span></li>
<li>/trunk/bridges/bridge_builtin_features.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/chan_dahdi.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/chan_mgcp.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/chan_misdn.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/chan_sip.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/chan_unistim.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/sig_analog.c <span style="color: grey">(390144)</span></li>
<li>/trunk/channels/sip/include/sip.h <span style="color: grey">(390144)</span></li>
<li>/trunk/include/asterisk/bridging_features.h <span style="color: grey">(390144)</span></li>
<li>/trunk/include/asterisk/channel.h <span style="color: grey">(390144)</span></li>
<li>/trunk/include/asterisk/features.h <span style="color: grey">(390144)</span></li>
<li>/trunk/include/asterisk/features_config.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/main/bridging.c <span style="color: grey">(390144)</span></li>
<li>/trunk/main/features.c <span style="color: grey">(390144)</span></li>
<li>/trunk/main/features_config.c <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/main/manager.c <span style="color: grey">(390144)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2578/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>