[asterisk-dev] Calendaring API

[Terry Wilson]

> Terry: What would be required to get more details in the
> ${CALENDAR_BUSY()} function?  It would be useful to get more back
> other than just the status.  It would be useful to get back any of
> the data that you expose with CALENDAR_EVENT, so the dialplan can do
> something like "John has an incoming call, but he is in a meeting.
> If the caller is the meeting organizer, then send the call through to
> his cell phone, otherwise send to voicemail."

Well, it might be a little bit difficult to do completely right.   
There is no reason why there can't be multiple overlapping events in a  
calendar.  So having a ${CALENDAR_BUSY(<calendar>)} function provide  
meaningful data as to what is "going on right now" isn't going to be  
able to provide a definitive 1 to 1 mapping.  Now, you could handle  
the common case pretty easily, and then detect if your query for "now"  
received multiple events and then make that known to the dialplan  
somehow...

> It would be interesting to make this "realtime" capable, also, since
> I expect this feature will be one of the ones that is very frequently
> used by larger installations of Asterisk systems that are managed
> externally.

Agreed, this is something I think needs to be added.

> Actually, it also might be useful to do something like this, where
> both named calendars out of calendar.conf could be used as well as
> fully-qualified calendar URLs in an ad-hoc fashion:
>
> Looks in calendar called 'calendar1' and returns status (same result  
> for each):
> ${CALENDAR_BUSY(calendar1)}
> ${CALENDAR_BUSY(calendar1,status)}
>
> Looks in calendar called 'calendar1' and returns organizer:
> ${CALENDAR_BUSY(calendar1,organizer}}
>
> Looks in calendar referenced by URL and returns organizer:
> ${CALENDAR_BUSY(ical/jdoe:supersecret at https://example.com/home/jdoe/Calendar/,organizer) 
> }
>
>
> Of course, if you wanted to extend this ad-hoc method into the
> resources as well (i.e.: hints) then you'd have to come up with some
> different separator between the calendar type ("ical" or "exchange")
> and in the rest of the URL, or embed it in quotes or something, since
> "/" characters can't be used in device state providers.

With the above caveat with regards to concurrent events, I think I  
would rather either have a separate $ 
{CALENDAR_STATUS(<calendar>,<field>)} function, or rename  
CALENDAR_BUSY and have it == ${CALENDAR_STATUS(<calendar>,status)}.   
I'm not sure how I feel about the unnamed calendar idea.  It seems  
like added complexity as far as parsing the arguments to the function  
w/o a lot of benefit--especially if we add realtime support where it  
is easy to add a calendar w/o having to reload, etc.  It also  
encourages people to write ugly extensions.conf files where they have  
to do a lot of search and replace if they change their password,  
etc.  :-)  If I knew of a compelling reason to put it in, though, I  
might feel differently (for some reason, people don't always write  
their extensions.conf files the way I do--it's really weird...).

Terry