<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 20, 2008, at 4:01 PM, Terry Wilson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">I was thinking a bit about the caching issue. Perhaps there is a way<br></blockquote><blockquote type="cite">to temporarily cache and refresh unnamed calendars automatically? In<br></blockquote><blockquote type="cite">the [general] section of calendars.conf, there might be something<br></blockquote><blockquote type="cite">like this:<br></blockquote><blockquote type="cite">[general]<br></blockquote><blockquote type="cite">;<br></blockquote><blockquote type="cite">; Do we cache un-named calendars that are referenced in the dialplan?<br></blockquote><blockquote type="cite">; This makes subsequent responses faster, which is important during<br></blockquote><blockquote type="cite">; call processing, and also lowers network lag for full calendar<br></blockquote><blockquote type="cite">; imports.<br></blockquote><blockquote type="cite">;<br></blockquote><blockquote type="cite">cacheunnamed=yes<br></blockquote><blockquote type="cite">;<br></blockquote><blockquote type="cite">; How long do we maintain state for an un-named calendar? (seconds)<br></blockquote><blockquote type="cite">; If the calendar is unused, and this timer expires, the calendar<br></blockquote><blockquote type="cite">; is "forgotten" until next requested. However, if the calendar is<br></blockquote><blockquote type="cite">; queried, the counter is reset to zero and starts again.<br></blockquote><blockquote type="cite">;<br></blockquote><blockquote type="cite">cacheduration=86400<br></blockquote><blockquote type="cite">;<br></blockquote><blockquote type="cite">; Un-named calendars are refreshed this often (seconds) for the <br></blockquote><blockquote type="cite">duration<br></blockquote><blockquote type="cite">; that they live in the cache. This keeps them "useful" to <br></blockquote><blockquote type="cite">subsequent<br></blockquote><blockquote type="cite">; queries without having to pause to re-load the entire calendar.<br></blockquote><blockquote type="cite">; If the calendar is unreachable on a refresh, the data is maintained<br></blockquote><blockquote type="cite">; until the cacheduration timer expires.<br></blockquote><blockquote type="cite">;<br></blockquote><blockquote type="cite">refresh=3600<br></blockquote><blockquote type="cite"><br></blockquote><br>I agree that we need something like the above for the "please don't <br>thrash the calendar server" issue. In addition I've been thinking <br>about CALENDAR_STATUS some more and I've decided that I don't think <br>our proposal quite works, yet. If we call CALENDAR_STATUS() and it <br>has more than one result, and we cache the calendar data, pull back <br>the number of results, and decide in the dialplan we want the second <br>one...there is no guarantee that the next call to CALENDAR_STATUS() <br>will have the same number of results. Lets say you are doing a query <br>based on the ${EPOCH}: the epoch changes between first and second <br>query. All of the sudden you may have 1 result instead of 2 and the <br>query requesting the data from result 2 is no longer there. Or you <br>only have one result when you do the initial call, and EPOCH changes <br>farther down the dialplan and all of the sudden you have no results <br>anymore. You can work around this by setting variables for start/end <br>that don't change, I suppose, but the function itself doesn't really <br>encourage it and the bug in the dialplan logic that allowed it to <br>happen could lead to people missing info, etc. And it would still be <br>confusing in the case if a cache timeout occurs in the middle of <br>dialplan execution. So to make a long story short, I think queries <br>should be atomic.<br><br>My current thinking is maybe we have a function <br>CALENDAR_QUERY(calendar, start, end) which queries all fields of the <br>calendar between start and end (ala SELECT * FROM ...) and it returns <br>a result ID. Then we can have CALENDAR_INFO(resultid, field, <br>eventnum). I think we can just store the calendar event info in a <br>datastore on the channel so it exists as long as the channel does. So <br>you end up with something like:<br><br>exten => 123,1,Set(id=${CALENDAR_QUERY(mycalendar, ${EPOCH}, $[{$ <br>{EPOCH} + 1800])})<br>exten => 123,n,NoOp(${CALENDAR_INFO(${id}, eventnum)} events returned)<br>exten => 123,n,NoOp(First summary is ${CALENDAR_INFO(${id}, summary, <br>1)})<br><br>etc. You can thrown in loops, etc. to your hearts content and the <br>data is guaranteed to be consistent for the life of the channel. If <br>you want to do a query on another timeframe, store it right along side <br>the last query, reference by the correct id, etc. Maybe throw in a <br>CALENDAR_QUERY_FREE() function for people who for some reason want to <br>free the results before the end of the call? This format at least <br>makes it explicit that the result set is over a specific time frame <br>and that we are dealing with cached information, as opposed to hiding <br>it from the user. Anyway, those are my current thoughts. Let me know <br>what you think.<br><br>Terry<br></div></blockquote></div><div><br></div><div><br></div><div>I think this is a reasonable approach, though it does add some complexity burden for the dialplan creator. This would solve the trivial problem of time passing between sequential queries in the same dialplan path, even though not using ${EPOCH} in query criteria would remove that issue, as you note. It also solves the more difficult but probably more rare problem of calendar events being added/deleted/changed over the course of a "call", which I think is the more fundamental problem. I'd be in favor of the design you suggest.</div><div><br></div><div>Perhaps I am wildly behind the times with some of the more esoteric features of Asterisk, but I don't believe that nesting variables inside of string values (aka: string macros) is possible - that would make coding this a bit easier in the dialplan, though it would circumvent the very reason you're proposing to make this atomic. :-) </div><div><br></div><div>I suspect that a "FREE" command is unnecessary. Calendar lookup elements should automatically be freed at Hangup; I don't think so many would be created in a single call that they would consume enough resources to worry about having to Free them inside the call.</div><div><br></div><div>What would you suggest as the ID number as the base of a CALENDAR_QUERY?</div><div><br></div><div>My comments on ordering multiple results still I hope hold water (not forwarded above for sake of brevity.)</div><div><br></div><div>JT</div><div><br></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="font-family: Tahoma; font-size: 13px; ">John Todd<br><a href="mailto:jtodd@digium.com">jtodd@digium.com</a> +1-256-428-6083<br>Asterisk Open Source Community Director</span></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div><br></body></html>