<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>24586</bug_id>
          
          <creation_ts>2014-02-08 00:20:47 +0000</creation_ts>
          <short_desc>Remove FileList</short_desc>
          <delta_ts>2015-10-19 15:47:52 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebAppsWG</product>
          <component>File API</component>
          <version>unspecified</version>
          <rep_platform>PC</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          <dependson>23682</dependson>
          <blocked>17125</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Jonas Sicking (Not reading bugmail)">jonas</reporter>
          <assigned_to name="Arun">arun</assigned_to>
          <cc>costan</cc>
    
    <cc>jan.varga</cc>
    
    <cc>public-webapps</cc>
          
          <qa_contact>public-webapps-bugzilla</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>100075</commentid>
    <comment_count>0</comment_count>
    <who name="Jonas Sicking (Not reading bugmail)">jonas</who>
    <bug_when>2014-02-08 00:20:47 +0000</bug_when>
    <thetext>Bug 23682 seems to be solving the issue of how to return a JS-array of Foo objects rather than having to introduce new FooList types.

This means that we can remove FileList.

This should be a backwards compatible change spec-wise. Some implementations supports the syntax myfilelist.item(5) which would be lost in this change. But given that no one has asked for the .item function to be brought back, hopefully this should be fine.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>100107</commentid>
    <comment_count>1</comment_count>
    <who name="Jan Varga">jan.varga</who>
    <bug_when>2014-02-10 09:46:27 +0000</bug_when>
    <thetext>So we don&apos;t have to fix IDB implementation to support it :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>100166</commentid>
    <comment_count>2</comment_count>
    <who name="Arun">arun</who>
    <bug_when>2014-02-10 15:49:31 +0000</bug_when>
    <thetext>OK, but what is the best strategy for feature requests?  For example, Bug 17125 calls for a .drop(itemNumber) method to be added. Without a custom interface, what can we extend or work with?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>100177</commentid>
    <comment_count>3</comment_count>
    <who name="Jonas Sicking (Not reading bugmail)">jonas</who>
    <bug_when>2014-02-10 17:10:44 +0000</bug_when>
    <thetext>That&apos;s the beauty. If we use the proposed solution in bug 23682 and use Arrays rather than FileList, then we leverage the existing feature set of Arrays. I.e. things like FileList.drop(whatever) isn&apos;t needed since Arrays already have that functionality.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>100183</commentid>
    <comment_count>4</comment_count>
    <who name="Arun">arun</who>
    <bug_when>2014-02-10 17:55:10 +0000</bug_when>
    <thetext>(In reply to Jonas Sicking from comment #3)
&gt; That&apos;s the beauty. If we use the proposed solution in bug 23682 and use
&gt; Arrays rather than FileList, then we leverage the existing feature set of
&gt; Arrays. I.e. things like FileList.drop(whatever) isn&apos;t needed since Arrays
&gt; already have that functionality.

I guess in the case of something like FileList, all &quot;new proposal&quot; operations (like .drop(item)) will be list operations envisioned for an iterable type, which I guess Array gives us out of the box.

OK, I&apos;m sold :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>115073</commentid>
    <comment_count>5</comment_count>
    <who name="Arun">arun</who>
    <bug_when>2014-11-18 20:52:42 +0000</bug_when>
    <thetext>We&apos;ve marked this &quot;at risk&quot; but haven&apos;t removed it, owing to the other platform bits that need to happen.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>115075</commentid>
    <comment_count>6</comment_count>
    <who name="Jonas Sicking (Not reading bugmail)">jonas</who>
    <bug_when>2014-11-18 21:06:26 +0000</bug_when>
    <thetext>Once bug 23682 is fixed, we can probably just do |typedef FileList FrozenArray&lt;File&gt;;|. This way we don&apos;t have to depend on others to remove it from their spec.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>123770</commentid>
    <comment_count>7</comment_count>
    <who name="Arun">arun</who>
    <bug_when>2015-10-19 15:47:52 +0000</bug_when>
    <thetext>We&apos;re migrating File API bugs to GitHub Issues; this one is: https://github.com/w3c/FileAPI/issues/19</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>