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

On 23/04/2013, at 1:18, "Mandyam, Giridhar" <mandyam@quicinc.com> wrote:

>>> 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?
> 
> Don't own the copyright - IEEE does.  I'll see what I can do.

Thanks. Worst case, email a me a link where I can buy it. 

>> 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.
> 
> When file system is unable to provide is unable to provide the media type, then the manifest could be a source.

Yes, but this never happens AFAIK as the formats supported by browsers is pretty stable. And even if this was added, it does not help runtimes that don't support a particular type as there is no means to do content negotiation.

>  I am not saying that the MIME Sniffing spec cannot be extended to cover these use cases however, but it is limiting to rely on this doc as the only possible way to determine MIME type.

I agree, but again, which devs are not being catered to by sniffing? Is some significant number of apps affected or is there any developer asking for this? 

If we can't find anyone asking for this from existing runtimes, then this would fall in the "nice to have" category. 

My personal experience had been that this has never come up as an issue in practice. But would like to hear from other vendors if their dev communities have asked for this?

>> 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.
> 
> The first sentence in Section 6.4:  "This section describes how a user agent retrieves files from inside a container by dereferencing an app: URI, and how a user agent handles error conditions (e.g., when a file is not found)."  
> 
> To me this means that the UA is directly generating the response to the XHR request.  This means that the UA must differentiate between XHR requests that are targeted to the network, and XHR requests targeted to the file system.  I believe this imposes requirements on the XHR implementation.

Kinda, but implicitly. If there are explicit requirements or interop issues that arise, we can just file bugs on XHR and get the Editor of that spec (Anne) to add any missing bits of support for app:. XHR already has bits about dealing with Blob, so there is no reason not to add some text about app: if needed. Anne can also probably provide us with good feedback on app:. We should probably email him soon to make sure he helps us make this work smoothly.

Received on Tuesday, 23 April 2013 05:16:48 UTC