[asterisk-dev] Calendaring API

[John Todd]

At 3:54 PM -0500 2008/10/7, Terry Wilson wrote:
>
>>  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...
>[snip]

I would suggest that it might provide the most specific information 
first if not given a specific event to fetch.  Perhaps making it 
similar to the ENUMQUERY method of fetching multiple possible results?

If I have a multi-day, "all-day" calendar event (like I often do, 
denoting that I'm in a certain city) and I also have a meeting 
scheduled from 13:00-14:00, and the time is 13:20, then it should 
respond back with the default values... err...


In fact, between the last sentence and this one, I've spent at least 
two hours thinking about this and writing one of my famous 
"It'll-never-be-implemented" config files.  I'll follow up in a 
totally new post.

>  > 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...).


Ack!  I would hope that only a few people ever hardcode their 
passwords into the extensions.conf file.  The real hope is that 
variables are used - I only put a fully qualified and non-ambiguous 
example in there so it was clear how it might work.  Using variables 
as replacements for those fields, it would be quickly possible to 
grab data from dynamic open calendars - think about the calendars on 
Google Calendars for various bands, as an example.

Instead of creating a whole new calendar subscription process, this 
would allow on-the-fly grabs of data from the calendar resource.



PS: "core show function CALENDAR_BUSY" should describe the possible 
result codes currently available, even if you don't expand it to do 
the named field stuff discussed above.

JT

-- 
John Todd
jtodd at digium.com        +1-256-428-6083
Asterisk Open Source Community Director