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

On 22/04/2013, at 20:44, "Mandyam, Giridhar" <mandyam@quicinc.com> wrote:

>> 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.

Sorry, did not intend it to be loaded. I was just responding based on you mentioning a proxy in the other email.

>  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.

Haven't looked online, but would like to read this. Can you email it to me if not publicly available? 

> 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.

I've thought about the same thing for many years (and might have even proposed a few things a few years ago on the WebAppsWG list - like the .htaccess like syntax from Apache for associating MIME and file extensions). I  just always failed to come up with a string use case that is not covered by sniffing. 

Can you think of a use case? 

> 
>> 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 .

The point is that it might fail altogether because app:// over xhr is not supported at all. I.e., throws an unexpected exception on runtime A but works on B and C.  

> 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?

I don't think we are putting any requirement on XHR? All that is being defined is HTTP response semantics so things "just work" (tm)... Or that's the goal. 

> 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.

I think it's really up to implementers now to weigh in if they are willing to implement the HTTP-like behavior. I'll only specify things that people want to implement. 


> 
> -----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 21:44:05 UTC