Whatever the eventual solution to this problem, it should be the user of
the API driving the decision how to get the data.
On Wed, Jan 16, 2013 at 4:56 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
> On Wed, Jan 16, 2013 at 7:50 AM, Glenn Maynard <gl...@zewt.org> wrote:
>
>> On Wed, Jan 16, 2013 at 9:40 AM, Florian Bösch <pya...@gmail.com> wrote:
>>
>>> Perhaps we should think of a better scheme to export data than toFoo().
>>> Maybe toData('url'), toData('arraybuffer') toData('blob') or perhaps
>>> toData(URL), toData(ArrayBuffer) or toData(Blob). I tend to think that if
>>> you're starting to write toA, toB, toC, toX methods on an object, you've
>>> not thought this really trough what's a parameter, and what's a method.
>>>
>>
>> We should be avoiding the need to return data in a bunch of different
>> interfaces in the first place. If the data is large, or takes a long or
>> nondeterministic amount of time to create (eg. something that would be
>> async in the UI thread), return a Blob; otherwise return an ArrayBuffer.
>> The user can convert from there as needed.
>>
>
> Well, the problem is that we fundamentally screwed up when we specced
> Blob. It has a synchronous size getter which negates many of the
> advantages of FileReader extracing data asynchronously. For something like
> image encoding (that involves compression), where you have to perform the
> operation to know the size, Blob and ArrayBuffer are effectively
> interchangeable from the implementation perspective, since both require you
> to perform the operation up front.
>
> - Kyle
>
