- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Fri, 5 Sep 2008 01:00:06 +0100
- To: "Sullivan, Bryan" <BS3131@att.com>
- Cc: public-webapps@w3.org
Hi Bryan, On Thu, Sep 4, 2008 at 6:22 AM, Sullivan, Bryan <BS3131@att.com> wrote: > > To remain silent on the proxy configuration for Widgets raises a serious > problem with interoperability. The rationale above describes why. If a > particular service environment does not require a proxy, then the host > device will likely not be configured to use one. But the existence of that > case is not a valid reason to ignore the case in which a proxy *is* required > and the host device is configured to use it. In that case, the widget > framework must use the proxy by default, or it is likely that web > applications will not work. > > Putting the burden on the widget developer to "use a proxy if you need one" > will not suffice either, because: > > - Widget developers will not always know the specific proxy > configuration required for each device, and each network which the device > can access. Having developers hard code or privately configure proxy > settings is not a scalable practice. > > - Proxy settings do change for various reasons, and are remotely > manageable (e.g. through OMA Device Management in mobile devices). > Hard-coded and privately configured proxy settings would be unaffected by > these changes. > > I request that the section on use of the user-configured and default proxy > be restored. I understand the problem and I personally don't mind putting it back in. However, I don't think this requirement can be addressed by normative text in any of our specifications. That is the reason we took it out in the first place. I mean, what would the normative text look like and into which specification of the Widget Family of Specifications would that text be included?... and how could this be tested in a test suite? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Friday, 5 September 2008 00:00:46 UTC