On Wed, Dec 16, 2009 at 11:58 AM, Jonas Sicking wrote:
> On Wed, Dec 16, 2009 at 9:55 AM, Robin Berjon wrote:
>> Hi Jonas,
>>
>> On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
>>> On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon wrote:
[Constructor(DOMString mediaType, DOMString fileName)]
>>
On Wed, Dec 16, 2009 at 9:55 AM, Robin Berjon wrote:
> Hi Jonas,
>
> On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
>> On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon wrote:
>>> [Constructor(DOMString mediaType, DOMString fileName)]
>>> interface FileWriter {
>>> // saving operations
>>> voi
Hi Jonas,
On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
> On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon wrote:
>> [Constructor(DOMString mediaType, DOMString fileName)]
>> interface FileWriter {
>>// saving operations
>>void save (DOMString content, optional DOMString encoding, optional
On Thu, Dec 10, 2009 at 10:23 AM, Peter O. Ussuri wrote:
> On Wed, Dec 9, 2009 at 4:30 PM, Eric Uhrhane wrote:
>
>> I lean toward an input
>> element that requires a user action to bring up the dialog box, but
>> I'm still thinking about it.
>
> Currently, a user action is needed to trigger the d
Hi Robin,
Glad to see this initial draft!
On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon wrote:
> [Constructor(DOMString mediaType, DOMString fileName)]
> interface FileWriter {
> // saving operations
> void save (DOMString content, optional DOMString encoding, optional
> DOMString endings)
On Wed, Dec 9, 2009 at 4:30 PM, Eric Uhrhane wrote:
> I lean toward an input
> element that requires a user action to bring up the dialog box, but
> I'm still thinking about it.
Currently, a user action is needed to trigger the download/save as
prompt, as most browsers will block (as part of the
On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon wrote:
> Hi Peter!
>
> On Dec 7, 2009, at 22:51 , Peter O. Ussuri wrote:
>> Fair point - playing with encoding(s) is probably not the right place here.
>> We thus can have just a binary builder and leave text/strings out of the
>> 'building' process a
On Mon, Dec 7, 2009 at 9:46 PM, Jonas Sicking wrote:
> On Mon, Dec 7, 2009 at 1:51 PM, Peter O. Ussuri wrote:
>> Hi Robin,
>> Thanks for your response!
>>
>>> Opera's original file system API also had encoding as part of its call
>>> that wrote out text — I think that's a bad idea. If you create
Hi Peter!
On Dec 7, 2009, at 22:51 , Peter O. Ussuri wrote:
> Fair point - playing with encoding(s) is probably not the right place here.
> We thus can have just a binary builder and leave text/strings out of the
> 'building' process altogether. FileWriter can be instructed later to
> write/sav
On Mon, Dec 7, 2009 at 1:51 PM, Peter O. Ussuri wrote:
> Hi Robin,
> Thanks for your response!
>
>> Opera's original file system API also had encoding as part of its call
>> that wrote out text — I think that's a bad idea. If you create a text
>> file/blob, you probably really want all of it to us
Hi Robin,
Thanks for your response!
Opera's original file system API also had encoding as part of its call that
> wrote out text — I think that's a bad idea. If you create a text file/blob,
> you probably really want all of it to use the same encoding. Allowing it to
> be specified on all calls i
Hi Peter,
On Nov 23, 2009, at 15:34 , Peter O. Ussuri wrote:
> May I suggest then a specific implementation, in order to move the process
> forward a bit. All names/signatures/behaviors below are intended to start the
> discussion only, and not as a draft or anything formal. :)
Thanks for your
Peter:
Thanks for sending this and the previous email. I'm sorry about
the slow response; it arrived just as I went away on holiday.
On Mon, Nov 23, 2009 at 6:34 AM, Peter O. Ussuri wrote:
>>> The current File API draft lets a web app to read the file, but there
>>> seems
>>> to be no easy
On Sat, Nov 28, 2009 at 11:38 AM, Nikunj R. Mehta
wrote:
>
> On Nov 20, 2009, at 1:37 PM, Peter O. Ussuri wrote:
>
> Hello!
>
> This is in reply to Eric Uhrhane's message, and other discussions [1]
>
> Various File API use cases discussed in this mailing list are designed to
> illustrate some kind
On Nov 20, 2009, at 1:37 PM, Peter O. Ussuri wrote:
Hello!
This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are
designed to illustrate some kind of expansion of existing browser
capabilities, with ensuing discus
>
> The current File API draft lets a web app to read the file, but there seems
>> to be no easy way for a web app to construct an arbitrary binary file and
>> trigger a SaveAs/download dialog, with the file name suggested by the app.
>>
>>
>
> I agree with this use case being a logical next step.
Peter O. Ussuri wrote:
Hello!
This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to
illustrate some kind of expansion of existing browser capabilities, with
ensuing discussion of potential new security ris
Hello!
This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to
illustrate some kind of expansion of existing browser capabilities, with
ensuing discussion of potential new security risks. However, there is one
18 matches
Mail list logo
