Re: Request to move app: URI to FPWD

The app: URI solves a real problem for Cordova-based packaged
applications. One of the oldest bugs we have in Cordova's issue tracker is
directly related to it, see [1].

Using just file:// URIs, getting references to in-app packages is
inconsistent and not cross-platform. Each implementation (Android, iOS,
etc) stores app packages in different locations. Take a look at the
issue's description for a specific example. app: URI solves this problem
very elegantly, providing an abstraction for users and a way to move from
one package application platform to another without having to recode or
rethink paths.

To be clear: this does not eliminate the need for file://, it works in
conjunction with it. Using file:// URIs and the HTML5 File API
(window.requestFileSystem, window.resolveLocalFileSystemURL), we can
access other important areas of the file system, like "Permanent" and
"Temporary" locations, which are common use cases, storage locations like
the SD card. Cordova uses these APIs extensively [2]. If you look through
the comments in [1], where Cordova committers were bikeshedding pretty
hard to figure the problem of accessing in-app contents in a
cross-platform way, we ended up concluding (but not implementing) that
adding more constants akin to PERMANENT and TEMPORARY to the HTML5 File
API was likely the best way to go about it. However, a protocol
abstraction works just as well and is more intuitive in my opinion.

I fully support this proposal.

Side/irrelevant comment: app: may be confusing in terms of what context it
applies. Does it work with hosted web applications? If it's purely
intended for package applications, perhaps pkg: is more explicit. Doesn't
matter to me that much but figured I'd throw it out there.

[1] https://issues.apache.org/jira/browse/CB-285
[2] 
http://cordova.apache.org/docs/en/2.6.0/cordova_file_file.md.html#LocalFile
System

On 4/18/13 9:26 AM, "Mandyam, Giridhar" <mandyam@quicinc.com> wrote:

>> If you can describe how it is possible to have a Web-based Execution
>>Model that does not feature a notion of origin ‹ and therefore
>>potentially a scheme ‹ then I can understand how this may not be clearly
>>in scope. But I really can't think of a situation in which this would
>>not be needed.
>
>We have a difference in understanding about the necessity of what is
>being proposed in this particular specification, and whether there in
>fact is a change in technical scope as anticipated by the charter.  I
>believe that Marcos is proposing something new as a replacement to
>file://, fs://, efs://.  Although the discussion in the F2F last week
>certainly helped me understand better why some people in the group feel a
>new URI scheme is needed, I am not convinced that existing schemes that
>have been used by native OS's for a long time are insufficient to meet
>the needs of Web OS implementations.   This spec covers new subject
>matter that was not anticipated by the charter IMO.
>
>This is different from, say, splitting the manifest into its own spec.  I
>don't think anyone joining this group believed that defining a manifest
>was outside the scope of the work for runtime execution and security
>(even with the sparse definition in the spec).
>
>> The alternative is to recharter this group, which will require voting
>>by the AC and everyone on this group to re-join.  I don't really
>>understand what that would achieve, unless it's a delaying tactic.
>
>I would request that you assume I am acting in good faith.
>
>-Giri
>-----Original Message-----
>From: Robin Berjon [mailto:robin@w3.org]
>Sent: Thursday, April 18, 2013 8:55 AM
>To: Mandyam, Giridhar
>Cc: Marcos Caceres; Mounir Lamouri; wonsuk11.lee@samsung.com;
>public-sysapps@w3.org
>Subject: Re: Request to move app: URI to FPWD
>
>On 18/04/2013 17:42 , Mandyam, Giridhar wrote:
>>> The point of a charter is to define the scope of deliverables so that
>>> participants can estimate the breadth of the patent commitment.
>>
>> This feature was not defined within scope of the charter based on our
>> understanding.  This is why I was asking for it to be called out in
>> the charter.
>
>If you can describe how it is possible to have a Web-based Execution
>Model that does not feature a notion of origin ‹ and therefore
>potentially a scheme ‹ then I can understand how this may not be clearly
>in scope. But I really can't think of a situation in which this would not
>be needed.
>
>Further note that after much discussion precisely on this topic, and
>before the chartering of this group, the community's consensus was that a
>new scheme was needed for the widgets case. Barring new technical
>information, due diligence in reviewing the field's best practices and
>consensus would lead to the conclusion that a scheme would be part of the
>runtime.
>
>> In order to move this forward, would it be possible to modify the
>> charter from its current form to better describe the deliverables of
>> the group?  If there is some commitment to this, we can withdraw our
>> objection.
>
>The charter is up for renewal in October 2014. I am confident that it
>will strive to provide as good a description of the group's deliverables
>as it can.
>
>The alternative is to recharter this group, which will require voting by
>the AC and everyone on this group to re-join. I don't really understand
>what that would achieve, unless it's a delaying tactic.
>
>--
>Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 18 April 2013 17:19:00 UTC