W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2004

Re: VoiceXML 2.1 Working Draft

From: Dave Burke <david.burke@voxpilot.com>
Date: Thu, 14 Oct 2004 15:24:57 +0100
Message-ID: <010e01c4b1f9$950ff300$7a34283e@db01.voxpilot.com>
To: "James Wilson" <James.Wilson@vecommerce.co.nz>, <www-voice@w3.org>

Hi, James.

The main issue with with this approach is security. Often the application
server can accept a HTTP request (POST of data in this case) but it usually
cannot make a HTTP request (open a TCP connection) back to the platform due
to firewalling/NAT. (Note also, that HTTP does have a mechanism to allow the
Webserver to refuse uploads i.e. 100 Continue). On a private LAN, the
approach you mention could work and appears to be a reasonable optimisation.

Cheers,

Dave

----- Original Message -----
From: "James Wilson" <James.Wilson@vecommerce.co.nz>
To: <www-voice@w3.org>
Sent: Thursday, October 14, 2004 8:59 AM
Subject: Re: VoiceXML 2.1 Working Draft


>
> Thx Dave
>
> It just seems inefficient downloading the data to the browser, then
posting
> the data back to the web server, and potentially again to another server.
> Media files are often large and web servers can be remote to the browser.
> The web server may not even want the data.
>
> In my application (biometric speaker verification), the web server will
need
> to pass the data on to yet another server - ie three transmissions through
3
> servers and there is a genuine time imperative.
>
> The URI could be transmitted just as easily and much more efficiently and
> the destination server could download the waveform once. Perhaps it would
be
> possible to support both methods concurrently without compromising the
> integrity of the langauge. ie make the URI available as a shadow variable
in
> addition to the waveform and leave it to the application to decide which
> method to use.
>
>
> Regards
> James
>
>
Received on Thursday, 14 October 2004 13:25:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:00 GMT