Re: How to get a FileWriter/BlobWriter/BlobSaver
On Fri, Jul 9, 2010 at 4:42 PM, Maciej Stachowiak wrote:
>
> On Jul 8, 2010, at 3:47 PM, Eric Uhrhane wrote:
>
>> On Fri, Jul 2, 2010 at 8:19 PM, Jonas Sicking wrote:
>>> On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane wrote:
The biggest unknown in the current BlobWriter spec [1] is how you
obtain one in the first place.
There are two current proposals, which I've summarized below. I've
heard only a few voices on this topic, and would love to get more
opinions. New proposals would be welcome as well.
If you favor one of the below, and don't think I've done it justice,
please do weigh in with further details.
Proposal A: a new input control.
You'd add markup such as or .
It could be styled however you please; it would pop up a standard
File-SaveAs dialog, so there's no security problem there. You'd
handle the event when the user selects a save location in order to
grab the BlobWriter.
Pluses:
It parallels .
It's user-initiated, so the default flow doesn't ever surprise the
user with a popup.
Proposal B: a new method on Window.
window.saveAs(function(blobWriter) { /* grab the writer and use it
*/}, function(error) {...});
Pluses:
It's a simple async API like many others we provide.
App developers are free to provide any UI or control flow they like.
In either case, we could add a parameter for the Blob, so that the
system knows what it's saving, and/or a suggested mime-type and base
name. Adding the Blob itself would let us eliminate the
writeFile()/save() call mentioned in [2], so that you'd only grab the
returned BlobWriter if you wanted to handle the progress events.
>>>
>>> I'm not a fan of the solution. In part because no
>>> actual input is occurring. If we really want something like that then
>>> I think reviving the old element is the way to go.
>>
>> The user is inputting a location at which to save the file.
>>
>>> However what I really think we should do is to provide some API which
>>> given a blob and an optional filename, asynchronously returns an
>>> object at which progress events are fired and which has an abort()
>>> function. I don't care much if this function lives on a new object,
>>> a'la SimpleFileWriter, or if it's added to something like the
>>> Navigator object.
>>
>> OK, I'm not hearing any support whatsoever for option A, so let's go
>> with something like SimpleFileWriter/BlobSaver.
>>
>> How about this?
>>
>> var blobSaver = window.saveAs(blob);
>> blobSaver.onerror = onError;
>> blobSaver.onwriteend = onWriteEnd;
>
> It would be great if we could avoid adding methods to Window with simple and
> common names like saveAs(), since they pollute the global namespace. saveAs
> sounds like a name that may well conflict with existing code. FileSaver or
> BlobSaver would be less likely to conflict, so perhaps the entry point can be
> a constructor, rather than a function.
More like this?
var writer = new SimpleFileWriter(blob, optionalName);
writer.onerror = onError;
writer.onwriteend = onWriteEnd;
> Other thoughts:
> - I still think the names should be prefixed with File, not Blob.
That's fine for the writers; I like your logic that a FooWriter writes
to a Foo, not from it.
I think the converse is true for a reader, so BlobReader makes the most sense.
> - What would the behavior be? Would this pop up a dialog where the user picks
> a file? If so, should it be subject to a user gesture limitation?
Should we spec that, or leave it loose?
One option I was just discussing over here was that if it's in
response to a user gesture, it pops up a SaveAs dialog; if it's not,
it goes to an infobar. I don't want to spec this so closely that UAs
can't experiment a bit.
> - Part of the objection to is because there is no input
> occuring. But HTML5 also has an element. Perhaps
> is an option worth considering?
>
>
> Regards,
> Maciej
>
>
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Fri, 9 Jul 2010, Maciej Stachowiak wrote: > > - Part of the objection to is because there is no > input occuring. But HTML5 also has an element. Perhaps type=file> is an option worth considering? is more like than . We could reintroduce though if people want an in-page UA-feature UI. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Jul 8, 2010, at 3:47 PM, Eric Uhrhane wrote:
> On Fri, Jul 2, 2010 at 8:19 PM, Jonas Sicking wrote:
>> On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane wrote:
>>> The biggest unknown in the current BlobWriter spec [1] is how you
>>> obtain one in the first place.
>>> There are two current proposals, which I've summarized below. I've
>>> heard only a few voices on this topic, and would love to get more
>>> opinions. New proposals would be welcome as well.
>>>
>>> If you favor one of the below, and don't think I've done it justice,
>>> please do weigh in with further details.
>>>
>>>
>>> Proposal A: a new input control.
>>>
>>> You'd add markup such as or .
>>> It could be styled however you please; it would pop up a standard
>>> File-SaveAs dialog, so there's no security problem there. You'd
>>> handle the event when the user selects a save location in order to
>>> grab the BlobWriter.
>>>
>>> Pluses:
>>> It parallels .
>>> It's user-initiated, so the default flow doesn't ever surprise the
>>> user with a popup.
>>>
>>>
>>> Proposal B: a new method on Window.
>>>
>>> window.saveAs(function(blobWriter) { /* grab the writer and use it
>>> */}, function(error) {...});
>>>
>>> Pluses:
>>> It's a simple async API like many others we provide.
>>> App developers are free to provide any UI or control flow they like.
>>>
>>>
>>> In either case, we could add a parameter for the Blob, so that the
>>> system knows what it's saving, and/or a suggested mime-type and base
>>> name. Adding the Blob itself would let us eliminate the
>>> writeFile()/save() call mentioned in [2], so that you'd only grab the
>>> returned BlobWriter if you wanted to handle the progress events.
>>
>> I'm not a fan of the solution. In part because no
>> actual input is occurring. If we really want something like that then
>> I think reviving the old element is the way to go.
>
> The user is inputting a location at which to save the file.
>
>> However what I really think we should do is to provide some API which
>> given a blob and an optional filename, asynchronously returns an
>> object at which progress events are fired and which has an abort()
>> function. I don't care much if this function lives on a new object,
>> a'la SimpleFileWriter, or if it's added to something like the
>> Navigator object.
>
> OK, I'm not hearing any support whatsoever for option A, so let's go
> with something like SimpleFileWriter/BlobSaver.
>
> How about this?
>
>var blobSaver = window.saveAs(blob);
>blobSaver.onerror = onError;
>blobSaver.onwriteend = onWriteEnd;
It would be great if we could avoid adding methods to Window with simple and
common names like saveAs(), since they pollute the global namespace. saveAs
sounds like a name that may well conflict with existing code. FileSaver or
BlobSaver would be less likely to conflict, so perhaps the entry point can be a
constructor, rather than a function.
Other thoughts:
- I still think the names should be prefixed with File, not Blob.
- What would the behavior be? Would this pop up a dialog where the user picks a
file? If so, should it be subject to a user gesture limitation?
- Part of the objection to is because there is no input
occuring. But HTML5 also has an element. Perhaps
is an option worth considering?
Regards,
Maciej
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Fri, Jul 2, 2010 at 8:19 PM, Jonas Sicking wrote:
> On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane wrote:
>> The biggest unknown in the current BlobWriter spec [1] is how you
>> obtain one in the first place.
>> There are two current proposals, which I've summarized below. I've
>> heard only a few voices on this topic, and would love to get more
>> opinions. New proposals would be welcome as well.
>>
>> If you favor one of the below, and don't think I've done it justice,
>> please do weigh in with further details.
>>
>>
>> Proposal A: a new input control.
>>
>> You'd add markup such as or .
>> It could be styled however you please; it would pop up a standard
>> File-SaveAs dialog, so there's no security problem there. You'd
>> handle the event when the user selects a save location in order to
>> grab the BlobWriter.
>>
>> Pluses:
>> It parallels .
>> It's user-initiated, so the default flow doesn't ever surprise the
>> user with a popup.
>>
>>
>> Proposal B: a new method on Window.
>>
>> window.saveAs(function(blobWriter) { /* grab the writer and use it
>> */}, function(error) {...});
>>
>> Pluses:
>> It's a simple async API like many others we provide.
>> App developers are free to provide any UI or control flow they like.
>>
>>
>> In either case, we could add a parameter for the Blob, so that the
>> system knows what it's saving, and/or a suggested mime-type and base
>> name. Adding the Blob itself would let us eliminate the
>> writeFile()/save() call mentioned in [2], so that you'd only grab the
>> returned BlobWriter if you wanted to handle the progress events.
>
> I'm not a fan of the solution. In part because no
> actual input is occurring. If we really want something like that then
> I think reviving the old element is the way to go.
The user is inputting a location at which to save the file.
> However what I really think we should do is to provide some API which
> given a blob and an optional filename, asynchronously returns an
> object at which progress events are fired and which has an abort()
> function. I don't care much if this function lives on a new object,
> a'la SimpleFileWriter, or if it's added to something like the
> Navigator object.
OK, I'm not hearing any support whatsoever for option A, so let's go
with something like SimpleFileWriter/BlobSaver.
How about this?
var blobSaver = window.saveAs(blob);
blobSaver.onerror = onError;
blobSaver.onwriteend = onWriteEnd;
...
[where nothing actually happens until execution exits]
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane wrote:
> The biggest unknown in the current BlobWriter spec [1] is how you
> obtain one in the first place.
> There are two current proposals, which I've summarized below. I've
> heard only a few voices on this topic, and would love to get more
> opinions. New proposals would be welcome as well.
>
> If you favor one of the below, and don't think I've done it justice,
> please do weigh in with further details.
>
>
> Proposal A: a new input control.
>
> You'd add markup such as or .
> It could be styled however you please; it would pop up a standard
> File-SaveAs dialog, so there's no security problem there. You'd
> handle the event when the user selects a save location in order to
> grab the BlobWriter.
>
> Pluses:
> It parallels .
> It's user-initiated, so the default flow doesn't ever surprise the
> user with a popup.
>
>
> Proposal B: a new method on Window.
>
> window.saveAs(function(blobWriter) { /* grab the writer and use it
> */}, function(error) {...});
>
> Pluses:
> It's a simple async API like many others we provide.
> App developers are free to provide any UI or control flow they like.
>
>
> In either case, we could add a parameter for the Blob, so that the
> system knows what it's saving, and/or a suggested mime-type and base
> name. Adding the Blob itself would let us eliminate the
> writeFile()/save() call mentioned in [2], so that you'd only grab the
> returned BlobWriter if you wanted to handle the progress events.
I'm not a fan of the solution. In part because no
actual input is occurring. If we really want something like that then
I think reviving the old element is the way to go.
However what I really think we should do is to provide some API which
given a blob and an optional filename, asynchronously returns an
object at which progress events are fired and which has an abort()
function. I don't care much if this function lives on a new object,
a'la SimpleFileWriter, or if it's added to something like the
Navigator object.
/ Jonas
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Jul 2, 2010, at 00:31 , Eric Uhrhane wrote: > The biggest unknown in the current BlobWriter spec [1] is how you > obtain one in the first place. > There are two current proposals, which I've summarized below. I've > heard only a few voices on this topic, and would love to get more > opinions. New proposals would be welcome as well. I don't have a strong preference as to the exact shape and colour of the way in which a download can be triggered for a Blob, but I do believe that it ought to happen in a way that is as consistent as possible with the existing triggering of downloads in present browsers. That means that user interaction should *not* be a prerequisite since that isn't required today, and is very commonly used as such. -- Robin Berjon - http://berjon.com/
How to get a FileWriter/BlobWriter/BlobSaver
The biggest unknown in the current BlobWriter spec [1] is how you
obtain one in the first place.
There are two current proposals, which I've summarized below. I've
heard only a few voices on this topic, and would love to get more
opinions. New proposals would be welcome as well.
If you favor one of the below, and don't think I've done it justice,
please do weigh in with further details.
Proposal A: a new input control.
You'd add markup such as or .
It could be styled however you please; it would pop up a standard
File-SaveAs dialog, so there's no security problem there. You'd
handle the event when the user selects a save location in order to
grab the BlobWriter.
Pluses:
It parallels .
It's user-initiated, so the default flow doesn't ever surprise the
user with a popup.
Proposal B: a new method on Window.
window.saveAs(function(blobWriter) { /* grab the writer and use it
*/}, function(error) {...});
Pluses:
It's a simple async API like many others we provide.
App developers are free to provide any UI or control flow they like.
In either case, we could add a parameter for the Blob, so that the
system knows what it's saving, and/or a suggested mime-type and base
name. Adding the Blob itself would let us eliminate the
writeFile()/save() call mentioned in [2], so that you'd only grab the
returned BlobWriter if you wanted to handle the progress events.
Eric
[1] http://dev.w3.org/2009/dap/file-system/file-writer.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1223.html
