No subject
Fri Mar 15 02:20:01 CDT 2013
think more about the APIs between the different modules and how they
will interact, often resulting in better code. Almost always easier to
maintain as there are (in theory) clearly demarcated boundaries between
the modules. Sometimes at the cost of a little performance in terms of
CPU. Often though it does add complexity and slows down new features,
but in the long term the code is less spagethish and inevitably you most
likely won't regret splitting stuff.
The one risk with smaller modules is code duplication. So instead of
creating a new module that contains the shared code some people will
duplicate the code.
Just my 2c worth of thoughts. I hope it helps.
Kind Regards,
Jaco
--------------060809070708060200020309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">Hi,<br>
</font><br>
On 08/04/2013 23:49, David Lee wrote:<br>
</div>
<blockquote
cite="mid:20130408214911.22889.16288 at hotblack.digium.com"
type="cite">
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table style="border: 1px #c9c399 solid;" width="100%"
bgcolor="#f9f3c9" cellpadding="8">
<tbody>
<tr>
<td> This is an automatically generated e-mail. To reply,
visit: <a moz-do-not-send="true"
href="https://reviewboard.asterisk.org/r/2376/">https://reviewboard.asterisk.org/r/2376/</a>
</td>
</tr>
</tbody>
</table>
<br>
<div>
<table style="border: 1px solid #C0C0C0; border-collapse:
collapse; margin: 2px padding: 2px;" width="100%"
bgcolor="white" border="0">
<thead> <tr>
<th colspan="4" style="border-bottom: 1px solid #C0C0C0;
font-size: 9pt; padding: 4px 8px; text-align: left;"
bgcolor="#F0F0F0"> <a moz-do-not-send="true"
href="https://reviewboard.asterisk.org/r/2376/diff/3/?file=35546#file35546line22"
style="color: black; font-weight: bold;
text-decoration: underline;">/trunk/res/res_stasis_http.make</a>
<span style="font-weight: normal;"> (Diff revision 3)
</span> </th>
</tr>
</thead> <tbody>
<tr>
<th style="border-right: 1px solid #C0C0C0;"
align="right" bgcolor="#b1ebb0"><br>
</th>
<td width="50%" bgcolor="#c5ffc4"><br>
</td>
<th style="border-left: 1px solid #C0C0C0; border-right:
1px solid #C0C0C0;" align="right" bgcolor="#b1ebb0"><font
size="2">22</font></th>
<td width="50%" bgcolor="#c5ffc4">
<pre style="font-size: 8pt; line-height: 140%; margin: 0; ">res_stasis_http.so: stasis_http/resource_asterisk.o stasis_http/resource_bridges.o stasis_http/resource_channels.o stasis_http/resource_endpoints.o stasis_http/resource_events.o stasis_http/resource_recordings.o stasis_http/resources.o</pre>
</td>
</tr>
</tbody>
</table>
<pre style="margin-left: 2em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Something I've gone back and forth over is whether each resource should be its own res_ module, or if they should be linked together into a single res_stasis_http module.
The current code links everything into a single module. I've given it some thought, and it wouldn't be a huge change to go the multi-module route.
This would break up the generated res/stasis_http/resources.c into several generated files. It makes the RESTful API more extensible, since they will be loaded dynamically instead of being specified in a single file.
I'll be giving this some more thought, but does anyone else have comments they'd like to add?</pre>
</div>
</div>
</blockquote>
Yes, there are pros and cons both ways (which is probably why you
can't make up your mind). As a sysadmin I like the ability to load
less code (both a smaller memory footprint, as well as less code
that can execute and crash). At the same time, I've found that
working with "autoload=no" has certain disadvantages too
(specifically, you might be aware of a function, you plonk it into
the dialplan and it just fails to work until you figure out which
module you need to load, and your module load list gets reasonably
long very quickly).<br>
<br>
In spite of the latter issue personally I still prefer multiple
smaller modules that does less (and working with autoload=no).<br>
<br>
From a programming perspective, having smaller modules forces one to
think more about the APIs between the different modules and how they
will interact, often resulting in better code. Almost always easier
to maintain as there are (in theory) clearly demarcated boundaries
between the modules. Sometimes at the cost of a little performance
in terms of CPU. Often though it does add complexity and slows down
new features, but in the long term the code is less spagethish and
inevitably you most likely won't regret splitting stuff.<br>
<br>
The one risk with smaller modules is code duplication. So instead
of creating a new module that contains the shared code some people
will duplicate the code.<br>
<br>
Just my 2c worth of thoughts. I hope it helps.<br>
<br>
Kind Regards,<br>
Jaco<br>
</body>
</html>
--------------060809070708060200020309--
--------------000605000301090806000102
Content-Type: text/x-vcard; charset=utf-8;
name="jaco.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="jaco.vcf"
begin:vcard
fn:Jaco Kroon
n:Kroon;Jaco
org:Ultimate Linux Solutions CC
email;internet:jaco at uls.co.za
title:Managing Member
tel;work:0873513298
tel;fax:0866488561
tel;cell:0845158255
url:http://www.uls.co.za/
version:2.1
end:vcard
--------------000605000301090806000102--
More information about the asterisk-dev
mailing list