[asterisk-dev] Calendaring and the bounds of Asterisk

[Russell Bryant]

Greetings,

As you all know from the discussions on this list, Terry Wilson has 
worked hard to bring calendar integration to Asterisk.  It is a very 
exciting new feature to be able to make available to our users. 
However, I have heard some concerns about whether this functionality 
makes sense architecturally.  I have thought about this, and would like 
to share my thoughts.

First of all, when I say "the bounds of Asterisk", I am talking about 
the bounds of Asterisk, the application.  I'm talking about the line 
that we must draw that defines what belongs in Asterisk, and what should 
be an external tool that uses an interface provided by Asterisk to 
deliver the functionality.  There is no problem with Asterisk the 
project distributing Asterisk the application, as well as a number of 
other tools that do one thing and do them well.

I would say that in the past, we have put almost everything into 
Asterisk.  However, the discussions about the next generation of 
Asterisk programming interfaces demonstrates a strong desire to move 
away from that.  I am very much in favor of a new focus on improving the 
Asterisk interfaces.  It is the only way for Asterisk to be scalable as 
a development platform.

Calendaring.  Does it belong in Asterisk?  The answer is not very 
obvious to me.

I'm going to go over the functionality that the calendaring patch 
provides and comment on them as they relate to this discussion.

1) Dialplan functions for querying or writing event information.

I don't have a problem with this part.  As long as we are in the 
business of developing our own programming language, I think it's fine.

It's feasible that this could be done outside of Asterisk.  For example, 
it could be another daemon that exposed this functionality via a DBUS 
API.  In fact, I think something like this could be really useful to 
applications other than Asterisk.  I think that something that 
streamlined the various calendar access methods through a consistent and 
easy to develop against interface, it would be welcomed by a number of 
other application developers.  However, just because this is possible, I 
don't think it's an argument against putting what we already have today 
in Asterisk.

2) Device State Provider

It's possible to provide custom device state from outside of Asterisk. 
You can set custom device states using the DEVICE_STATE() function via 
the manager interface.

I'm on the fence about this part.  This would be the only thing we have 
put in Asterisk for device state that is not directly representing state 
of something that lives in Asterisk.

3) Calendar event notification via call origination

This code also adds the ability to have Asterisk originate calls at a 
specified time period before an event occurs.  The options for call 
origination are very similar to the options provided via the other call 
origination methods (manager originate, CLI originate, call files).  I 
can definitely see how this is useful.  It can be used to remind people 
about meetings, or as a creative way to schedule things to happen on 
your phone system.

I'm on the fence about this one, as well.  This is on the border of 
writing business rules into Asterisk code, which we very much try to 
avoid.  Sure, some of the logic related to this can be done in the 
dialplan after the call has been originated.  However, I'm not sure if 
that covers everything.  Currently, the code will do a call origination 
for every calendar event at a configured time before the event.  Will 
there be a never-ending set of ways people would want to customize the 
criteria used for when to originate calls, and for which events?  If so, 
is that a reason to exclude the functionality that we have from Asterisk?


Comments welcome!

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.