RE: CfC: publish FPWD of "app: URI scheme"; deadline April 26th

> Without resulting to proxy middle ware, how?

a. The above is a bit of a loaded question in my opinion, since there seems to be an assumption that proxy middleware is always a bad thing.  Maybe I have not seen the same problems with on-device proxy middleware that you have.  In fact, I had written a paper a couple of years ago showing how proxy middleware can be used to increase battery life in mobile devices with respect to AJAX requests (both from native applications constructing web requests over TCP sockets, and from widgets using the old Konfabulator web runtime engine):  G. Mandyam, " Improving battery life for wireless web services through the use of a mobile proxy", IEEE  Int.'l Symposium on Personal, Indoor and Mobile Communications (PIMRC), 2010.

b. Even if we rule out the use of on-device proxies, I have provided feedback as to changes I would like to see regarding the approach outlined in Sec. 6.4.  The method currently outlined is not the only way to construct the response.  For instance, in my other email I had already provided an  example where a Supplied Media Type (as per ihttp://mimesniff.spec.whatwg.org/#supplied-media-type-detection-algorithm) could be provided by the manifest, yet this case is not covered specifically in the MIME Sniffing spec.

> Also, what happens if one runtime supports HTTP responses and another one doesn't - and the dev's application is depending on HTTP response driven events (e.g., onerror, onload)? This would likely cause interoperability issues, no?  

I am not sure I understand how this issue is different from any other type of XHR request to an arbitrary address. At least as far as I can tell http://www.w3.org/TR/XMLHttpRequest2/ does not seem to place requirements on the response sent by the target of an XHR request .  

Moreover, if there are normative requirements to be placed on the runtime's XHR implementation, why are they being specified in the Sysapps WG instead of WebApps WG?

If removing Sec. 6.4 is not palatable, another option would be to clearly mark the text as non-normative.  It could also be moved to an appendix in that case, but I'll leave that up to the editor.

-----Original Message-----
From: Marcos Caceres [mailto:w3c@marcosc.com] 
Sent: Monday, April 22, 2013 10:03 AM
To: Mandyam, Giridhar
Cc: public-sysapps@w3.org
Subject: Re: CfC: publish FPWD of "app: URI scheme"; deadline April 26th




On Monday, April 22, 2013 at 5:23 PM, Mandyam, Giridhar wrote:

> Hi Marcos,
> Thanks for the quick response.
> 
> Re: removal of Sec. 6.4 (section on dereferencing):
> 
> > Can you explain why you think this section should be dropped? (or if it's in the other email, just let me know.)
> 
> I do cover some technical issues with this section in the other email. In general, we believe this section is overly-prescriptive, and does not allow for other valid approaches. We believe the handling of XHR requests targeted to files in a package can be left up to the implementation.
> 

Without resulting to proxy middle ware, how? Also, what happens if one runtime supports HTTP responses and another one doesn't - and the dev's application is depending on HTTP response driven events (e.g., onerror, onload)? This would likely cause interoperability issues, no?

Received on Monday, 22 April 2013 19:47:15 UTC