Re: [File System APIs] If one is good, then two must be better?

[Ian Clelland]

The great thing about Cordova is that it doesn't have to be a single
platform -- every developer has the power to choose the APIs that they want
to use, and every published app is essentially running on its own custom
web platform.

I wasn't presenting the Cordova data point as "we're doing this already,
and it's going to be too much work to change now". Far from it; Cordova is
a flexible platform, and someone could write a plugin providing the
Mozilla-backed Filesystem API tomorrow, and it wouldn't cause any hardship
to developers who didn't choose to adopt it.

The point is exactly as Chaals has represented -- this just means that the
API is available in the wild, and being used by working Javascript
developers to access files right now. It's showing developer mindshare
momentum, rather than browser implementation inertia :)

Ian


On Wed, Feb 5, 2014 at 7:03 AM, Charles McCathie Nevile <
cha...@yandex-team.ru> wrote:

> On Tue, 04 Feb 2014 20:48:30 +0400, Arun Ranganathan 
> wrote:
>
>
>  On Feb 4, 2014, at 6:15 AM, Charles McCathie Nevile wrote:
>>
>>  On Mon, 03 Feb 2014 19:09:53 +0400, Arthur Barstow <
>>> art.bars...@nokia.com> wrote:
>>>
>>>  On 1/31/14 10:44 AM, ext Ian Clelland wrote:
>>>>
>>>>> Hi Art,
>>>>>
>>>>> For what it's worth, theFile API: Directories and System is also
>>>>> implemented (and supported) by Apache Cordova[1]. The implementation is
>>>>> essentially complete for mobile applications on Android, iOS and FireOS,
>>>>> with nearly-complete support on Blackberry and Windows Phone.
>>>>>
>>>>> While our plugin registry was counting downloads, it was the
>>>>> most-downloaded plugin for the platform by a wide margin, so I believe it
>>>>> is being used actively.
>>>>>
>>>>
>>>> Thanks for this information Ian!
>>>>
>>>>  I don't know if Cordova should count as a browser implementation for
>>>>> the purposes of this WG, but we are implementing the APIs and making them
>>>>> available to (hybrid) web application developers.
>>>>>
>>>>
>>>> The group has some flexibility regarding the specifics of the
>>>> interoperability criteria used to advance a spec along the Recommendation
>>>> track, but we haven't talked about the criteria for these specs since they
>>>> are still working drafts.
>>>>
>>>
>>> And the particular question here isn't about CR criteria, but about
>>> whether one or other approach is more likely to achieve the consensus of
>>> interoperable implementation.
>>>
>>> Which essentially means whether implementations are likely to switch, or
>>> credible future implementors have a strong preference for one over the
>>> other.
>>>
>>> In which case, what Cordova does (and more to the point what developers
>>> do with it) seems relevant information to consider as we try to find a
>>> consensus.
>>>
>>
>> Two interoperable implementations of a specification should determine the
>> way forward.
>>
>
> In this case we have multiple ways forward, and the fact that any of them
> have two implementations is an important but not sufficient indicator that
> they therefore have industry consensus as "the" way forward.
>
> For historical comparison, there were three at least reasonably
> interoperable independent browser implementations of WebSQL, when there
> were no real implementations of IndexedDB.
>
> There was one browser objecting to dropping WebSQL for IDB, 2 who said
> they would not implement it, and 4 (including 2 of the 3 webSQL
> implementors) saying they *would* implement IDB. We thus made the decision
> to focus on IDB. For any faults that it may have, it appears to have
> become the standard, which makes me suspect that focusing on it was the
> correct decision at the time.
>
> Similarly the issue here is not whether we can make a specification for
> one or the other approach that *could* be a standard, since it seems we
> can, but whether one or the other is a clear candidate to be a real
> standard - i.e. what people *will* actually do...
>
> I think one of the mistakes with IndexedDB (and appcache for that matter)
> was that the participants in the discussion were too heavily biased toward
> browser implementors, without enough input or involvement from "working
> developers". Which meant that we standardised something that didn't meet
> people&#x

Re: [File System APIs] If one is good, then two must be better?

[Ian Clelland]

Hi Art,

For what it's worth, the File API: Directories and System is also
implemented (and supported) by Apache Cordova[1]. The implementation is
essentially complete for mobile applications on Android, iOS and FireOS,
with nearly-complete support on Blackberry and Windows Phone.

While our plugin registry was counting downloads, it was the
most-downloaded plugin for the platform by a wide margin, so I believe it
is being used actively.

I don't know if Cordova should count as a browser implementation for the
purposes of this WG, but we are implementing the APIs and making them
available to (hybrid) web application developers.


[1] 



On Fri, Jan 31, 2014 at 10:21 AM, Arthur Barstow wrote:

> Hi Eric, Arun, Jonas, All,
>
> During the review of the first draft of WebApps' proposed charter
> extension, Marcos raised (indirectly) a question [1] about the plan for
> WebApps' various file system APIs and I agreed to followup.
>
> We have the two specs that Eric edits:
>
> * File API: Writer  file-system/file-writer.html>. The last ED update was 30-Jan-2013 and
> last TR publication was 17-Apr-2012  file-writer-api-20120417/>.
>
> * File API: Directories and System  file-system/file-dir-sys.html>. The last ED update was and last TR
> publication was 17-Apr-2012  file-system-api-20120417/>.
>
> We also have this spec from Arun and Jonas:
>
> * FileSystem API . The
> last update of the ED was 2-Oct-2013 and this spec has not been published
> as a TR.
>
> My understanding is the only implementation of Eric's APIs is Chrome. I do
> not know the implementation status of Mozilla's spec. If anyone has
> additional information about the implementation status or plans of either
> effort, please let us know.
>
> The last discussion about the relationship between these different efforts
> was August 2013 [Aug-2013] and prior to that, there was some discussion
> during the April 2013 f2f meeting [April-2013].
>
> Ultimately, I think there is broad agreement a single API that is broadly
> implemented and deployed would be `best` (f.ex. reduces FUD, lightens
> implementation costs, lightens deployment costs, etc.). Although I would
> (still) like to be optimistic we can agree to converge on a single API,
> previous discussions about this do make me skeptical ...
>
> Eric, Arun, Jonas - can you agree and commit to converge your efforts,
> f.ex. just have a single API?
>
> All - if we can't get a commitment to converge these efforts:
>
> * Do we want to continue both efforts (and thus reflect this in the
> charter update)?
>
> * Should we take a vote/poll with a goal to select a single effort and to
> stop work on the effort that has less support?
>
> * Something else?
>
> Comments are welcome.
>
> -Thanks, ArtB
>
> [1]  2014JanMar/0093.html>
> [Aug-2013]  2013JulSep/0334.html>
> [April-2013] 
>
>
>
>
>
>

CfC: server-sent-events

[Ian Clelland]

e given absolute URL, that
> connection can be reused, instead of a new connection being established. All
> messages received up to this point are dispatched immediately, in this case.


If that is the case, then it appears that they could all share the same
connection. If they do, then the the close() method needs to be redefined
such that either a close() call on one of the EventSources implicitly calls
it on the rest, or else the user agent needs to maintain a count of
EventSources currently using the connection, and the close() method should
just cancel reconnections, and set the readyState attribute, and only close
the connection when that count goes to zero.

-- 
Regards,
Ian Clelland