[Voiceglue] On audio caching and HTTP cookies

[Robby Dermody]

Hi Doug,

Thanks again for working through this. Great explanation. 

Regarding determining static vs. dynamic fetches, couldn't you just parse
the URL apart to look for a querystring? E.g. if you see a ? in the
requested prompt filename, then assume it's a dynamic request? Certain
Cisco VoiceBrowsers take this approach (actually IP IVR will look for the
presence of .jsp, etc. I believe, at least when I was involved in working
with it ...yuck, bad approach there). However, if the querystring uses
a different form (e.g. RESTful semantics) or if a static filename has a
? character in it, this will break. This may not be as flexible as you
want, then.

Regarding the maxage approach then, that makes sense, as long as the
default maxage (e.g. if not explicitly specified in the <audio> step
and not set via a <property> tag) is set to something other than 0.
This would allow you to preserve backwards compatability, so that
adding this functionality doesn't break people's scripts
that just want to read in static audio prompts and don't explicitly
specify a maxage anywhere. In making dynamic queries, I'm fine
explicitly setting maxage in the <audio> prompt.

That aside, with my limited knowledge in this area, this seems to
be a place where different voicebrowser vendors will do different
things...is that what you've found?

Robby

----- Original Message -----
From: "Doug Campbell" <voiceglue at campbellcastle.com>
To: "General discussion about voiceglue" <voiceglue at voiceglue.org>
Sent: Monday, February 16, 2009 3:08:15 PM GMT -05:00 US/Canada Eastern
Subject: [Voiceglue] On audio caching and HTTP cookies

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
_______________________________________________
Voiceglue mailing list
Voiceglue at voiceglue.org
http://www.voiceglue.org/mailman/listinfo/voiceglue