[asterisk-dev] [Code Review] Calendaring API for Asterisk

[Terry Wilson]

> Great work, Terry!

Thanks!

> Do we need it to be a main/calendar.c module that is not loadable?

In my view, yes--at least preferably.  The individual calendar  
technology resource modules register themselves as calendar  
technologies with ast_calendar_register() in main/calendar.c much like  
channel technologies register themselves with ast_channel_register()  
in main/channel.c.  That code has to exist before they can register,  
so the cleanest way to do it was by making the basic calendar support  
part of the core.  There are no dependencies induced, and if calendar  
support isn't specifically enabled in calendar.conf, it won't do  
anything else.

I wanted there to be only one config file, and have it read only once  
and that to be controlled from main/calendar.c  Otherwise you end up  
reading the same config file multiple times from multiple calendar  
technology resources, or having multiple config files (1st way I  
designed it) for the different types of calendars.  If you want a GUI  
for configuration, you are just going to want to worry about  
configuring your calendars--some of which may have different types.   
Anyway, the above is my basis for designing it the way I did (at least  
the last time--this is my 3rd re-design of this so far, and the first  
one that I liked enough to make public).  Others may prefer other  
designs, though.

> Any way to convert this to a module?

Most of it already is modules (res_icalendar, res_caldav, and  
res_exchangecal).  You could hack around and check if the main  
calendar module was loaded in each of the technology modules, then  
load the module from those modules if it wasn't loaded (2nd way I  
designed it).  But that is an uglier solution in my mind.  I really  
hate the idea of loadable modules depending on each other--it just  
feels dirty to me.  If asterisk had a mechanism for enforcing a  
particular load order with modules specifying what their dependencies  
were, etc. then it wouldn't be too bad.  Unfortunately, when you go  
down that rabbit hole you have to deal with graphs and loops and it is  
probably much more trouble than it is worth.