[asterisk-dev] Calendaring API
Terry Wilson
twilson at digium.com
Mon Oct 20 18:01:01 CDT 2008
> I was thinking a bit about the caching issue. Perhaps there is a way
> to temporarily cache and refresh unnamed calendars automatically? In
> the [general] section of calendars.conf, there might be something
> like this:
> [general]
> ;
> ; Do we cache un-named calendars that are referenced in the dialplan?
> ; This makes subsequent responses faster, which is important during
> ; call processing, and also lowers network lag for full calendar
> ; imports.
> ;
> cacheunnamed=yes
> ;
> ; How long do we maintain state for an un-named calendar? (seconds)
> ; If the calendar is unused, and this timer expires, the calendar
> ; is "forgotten" until next requested. However, if the calendar is
> ; queried, the counter is reset to zero and starts again.
> ;
> cacheduration=86400
> ;
> ; Un-named calendars are refreshed this often (seconds) for the
> duration
> ; that they live in the cache. This keeps them "useful" to
> subsequent
> ; queries without having to pause to re-load the entire calendar.
> ; If the calendar is unreachable on a refresh, the data is maintained
> ; until the cacheduration timer expires.
> ;
> refresh=3600
>
I agree that we need something like the above for the "please don't
thrash the calendar server" issue. In addition I've been thinking
about CALENDAR_STATUS some more and I've decided that I don't think
our proposal quite works, yet. If we call CALENDAR_STATUS() and it
has more than one result, and we cache the calendar data, pull back
the number of results, and decide in the dialplan we want the second
one...there is no guarantee that the next call to CALENDAR_STATUS()
will have the same number of results. Lets say you are doing a query
based on the ${EPOCH}: the epoch changes between first and second
query. All of the sudden you may have 1 result instead of 2 and the
query requesting the data from result 2 is no longer there. Or you
only have one result when you do the initial call, and EPOCH changes
farther down the dialplan and all of the sudden you have no results
anymore. You can work around this by setting variables for start/end
that don't change, I suppose, but the function itself doesn't really
encourage it and the bug in the dialplan logic that allowed it to
happen could lead to people missing info, etc. And it would still be
confusing in the case if a cache timeout occurs in the middle of
dialplan execution. So to make a long story short, I think queries
should be atomic.
My current thinking is maybe we have a function
CALENDAR_QUERY(calendar, start, end) which queries all fields of the
calendar between start and end (ala SELECT * FROM ...) and it returns
a result ID. Then we can have CALENDAR_INFO(resultid, field,
eventnum). I think we can just store the calendar event info in a
datastore on the channel so it exists as long as the channel does. So
you end up with something like:
exten => 123,1,Set(id=${CALENDAR_QUERY(mycalendar, ${EPOCH}, $[{$
{EPOCH} + 1800])})
exten => 123,n,NoOp(${CALENDAR_INFO(${id}, eventnum)} events returned)
exten => 123,n,NoOp(First summary is ${CALENDAR_INFO(${id}, summary,
1)})
etc. You can thrown in loops, etc. to your hearts content and the
data is guaranteed to be consistent for the life of the channel. If
you want to do a query on another timeframe, store it right along side
the last query, reference by the correct id, etc. Maybe throw in a
CALENDAR_QUERY_FREE() function for people who for some reason want to
free the results before the end of the call? This format at least
makes it explicit that the result set is over a specific time frame
and that we are dealing with cached information, as opposed to hiding
it from the user. Anyway, those are my current thoughts. Let me know
what you think.
Terry
Terry
More information about the asterisk-dev
mailing list