[asterisk-dev] [Code Review] 2376: Adding RESTful API's to Asterisk

[Jaco Kroon]

Hi,

On 08/04/2013 23:49, David Lee wrote:
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2376/
>
>
> /trunk/res/res_stasis_http.make
> <https://reviewboard.asterisk.org/r/2376/diff/3/?file=35546#file35546line22>
> (Diff revision 3)
>
> 	
> 	22 	
> 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
>
> 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?
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).

In spite of the latter issue personally I still prefer multiple smaller
modules that does less (and working with autoload=no).