W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Not making partial result available during FileReader.readAsText()?

From: Jian Li <jianli@chromium.org>
Date: Tue, 13 Apr 2010 13:44:36 -0700
Message-ID: <o2ja95818c31004131344hc4d4bbd1l64492d6c871a6cf0@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
This is what I also feel. I am going to set total and loaded based on binary
data. Just want to make sure we're in the same page for those that are
spec-ed out clearly.

On Mon, Apr 12, 2010 at 5:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Unfortunately I think decoded data is impossible as you have no idea
> what the total amount of decoded data will be until you've decoded the
> entire file.
>
> / Jonas
>
> On Mon, Apr 12, 2010 at 4:35 PM, Jian Li <jianli@chromium.org> wrote:
> > This sounds good. I have one more question related to this.
> > What are we going to set for total and loaded attributes for
> ProgressEvent?
> > Is it based on the decoded text or the underlying binary data?
> >
> >
> > On Fri, Apr 9, 2010 at 6:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> I think the spec should say MUST here, rather than SHOULD. Streaming
> >> contents seems as useful for text files as for binary files.
> >>
> >> The one thing that was tricky for us when implementing this was
> >> charset detection. We can't really expose any data until we've decided
> >> what charset to decode it with. However when loading normal pages over
> >> http the same situation arises, and all major browsers support
> >> streaming there.
> >>
> >> So I consider it a bug that firefox doesn't support this yet. It's
> >> something we should fix.
> >>
> >> / Jonas
> >>
> >> On Fri, Apr 9, 2010 at 6:33 PM, Jian Li <jianli@chromium.org> wrote:
> >> > Should we really want to support this? As I know, FF 3.6 does not
> >> > support
> >> > this in its current FileReader implementation. I just want to
> understand
> >> > if
> >> > there is a strong need for this.
> >> >
> >> > On Fri, Apr 9, 2010 at 5:49 PM, Michael Nordman <michaeln@google.com>
> >> > wrote:
> >> >>
> >> >> Seems pretty clear from the snippet you provided, it says you SHOULD
> >> >> provide partially decoded results in the result attribute as progress
> >> >> is
> >> >> made.
> >> >>
> >> >> On Thu, Apr 8, 2010 at 8:31 PM, Jian Li <jianli@chromium.org> wrote:
> >> >>>
> >> >>> For FileReader.readAsText, the spec seems to allow partial file data
> >> >>> being decoded and saved in the result attribute when progress event
> is
> >> >>> fired:
> >> >>>
> >> >>> Make progress notifications. As the bytes from the fileBlob argument
> >> >>> are
> >> >>> read, user agents SHOULD ensure that on getting, the result
> attribute
> >> >>> returns partial file data representing the number of bytes currently
> >> >>> loaded
> >> >>> (as a fraction of the total) [ProgressEvents], decoded in memory
> >> >>> according
> >> >>> to the encoding determination.
> >> >>>
> >> >>> The partial file data read so far might not get decoded completely.
> >> >>> Could
> >> >>> we choose not to decode the partial result till we retrieve all the
> >> >>> data,
> >> >>> just like what FileReader.readAsDataURL does?
> >> >>
> >> >
> >> >
> >
> >
>
Received on Tuesday, 13 April 2010 20:45:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT