[Voiceglue] On audio caching and HTTP cookies

[Doug Campbell]

In implementing the changes for cookies and dynamically-generated
audio data loading, I have come across the following design issue.

I would appreciate feedback on any improvements I can make
regarding this issue.

If performance were not a concern, every HTTP request implied by
a VXML session would be made to the server (not cached), and would
contain the cookies that have been set during that session.

However, caching is important to performance, especially
when scaling to many simultaneous calls.  Caching can
occur either within a VXML session (private caching)
or across VXML sessions (shared caching).

Private caching should, theoretically, be governed by
HTTP and VXML caching directives, and therefore the programmer
can achieve the control he desires regarding the tradeoffs
between caching, cookies, and dynamically-generated content.
Unfortunately, private caching has limited performance
benefits if many calls are using the same data.

Shared caching prohibits the use of cookies to identify
a session and can violate the semantic transparency
of the requests.  But, shared caching can provide dramatic
performance benefits when many calls use the same data.

Currently, voiceglue performs private caching for non-audio
data (e.g. VXML pages) and shared caching for audio data.

The changes I am currently making will separate audio data
fetches into static versus dynamic fetches.  Static audio
fetches will continue to not send cookies and will get cached across
sessions, while dynamic audio fetches will send cookies and not
get cached at all.

The problem comes in determining which audio fetches are
static and which are dynamic.

While I would like to be able to determine static versus
dynamic audio fetches by examining the server HTTP headers
Expires: <now>, Cache-Control: no-cache, Cache-Control:
private, and Cache-Control: s-maxage=0, I cannot wait for the
server response as by then it is too late to have sent cookies.

So, I propose determining static audio fetches as those having
a VXML maxage attribute (or audiomaxage property if not defined)
not equal to 0.  Conversely, dynamic audio fetches have maxage
set to 0.  This gives the VXML script author full control over
whether to use the shared cache for any particular audio resource.

Anyone see isues with this?  Or a better way overall?

Doug Campbell