[asterisk-dev] Calendaring API

[Terry Wilson]

On Oct 8, 2008, at 11:19 AM, Daniel Hazelbaker wrote:

> On Oct 8, 2008, at 12:52 AM, John Todd wrote:
>
>> To top-summarize:
>>
>> 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:
>
> I am not up on CalDAV, but as I understand it it is just built on top
> of HTTP.  Wouldn't it be possible to use the same methods that web
> browsers use to determine if a web page has changed since the last
> time it was retrieved and parsed?  If it hasn't changed we use the in-
> memory cache, if it has then we retrieve it again.  I would still have
> a "forcecached" option to make a calendar be cached no matter what for
> x period of time if desired.  Most calendars don't get updated all
> that often, others (especially depending on client) might get updated
> all the time even if nothing actually changes.

It doesn't look to be the same exactly, but there are provisions for  
synchronization.  From the CalDAV RFC:

8.2.1.3. Synchronization Process If a client wants to support calendar  
data synchronization, as opposed to downloading calendar data each  
time it is needed, the client needs to cache the calendar object  
resource's URI and ETag, along with the actual calendar data. While  
the URI remains static for the lifetime of the calendar object  
resource, the ETag will change with each successive change to the  
calendar object resource. Thus, to synchronize a local data cache with  
the server, the client can first fetch the URI/ETag pairs for the time  
interval being considered, and compare those results with the cached  
data. Any cached component whose ETag differs from that on the server  
needs to be refreshed. In order to properly detect the changes between  
the server and client data, the client will need to keep a record of  
which calendar object resources have been created, changed, or deleted  
since the last synchronization operation so that it can reconcile  
those changes with the data on the server. Here's an example of how to  
do that: The client issues a CALDAV:calendar-query REPORT request for  
a specific time range and asks for only the DAV:getetag property to be  
returned
So we can do a lightweight query to see if the etag has changed, but  
lets say you have 5 calls per second hitting that query in the  
dialplan...that is why I like having everything cached that we're  
going to be querying.