[asterisk-dev] [Code Review] Calendaring API for Asterisk
twilson at digium.com
Thu Nov 13 02:31:17 CST 2008
> Great work, Terry!
> 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
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
> 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.
More information about the asterisk-dev