[whatwg] creating a new file via the File API

hi,
if you look at the generated files examples, what you can see there 
(again, only in chrome) is that
1/ I have some data in JS
2/ I create blobbuilder -> blob -> url to that blob
3/ I create a element with URL to that blob and  download attribute
4/ I initiate click on that link programmaticaly

the result is is that Save file dialog is opened and when save/ok button 
is hit, the blob data is stored in user selected file.
Yes, I'm using download attribute, but URL is JS blob (local data).
I do not see problem here. What are you missing?

And yes, I also do not see security issues here, nothing user cannot do 
today with regular download or programmer by uploading data to server 
and then download them...

B.




On 19.12.2011 6:26, David Karger wrote:
> Hi,
>
>    What you're doing is certainly connected, but I don't think it 
> solves the problem I outlined.  Your approach allows specification of 
> the download target as an attribute in html.   That's useful, but 
> what's still missing, and I consider important, is a way to connect 
> the html document to the "Save As" dialog available on all OSes. 
> <input> tags lead browsers to launch the "Open File" dialog, which 
> lets the user naturally navigate their file system to select a file to 
> open.   Browsers also launch the analogous "Save As" dialog, but 
> _only_ when you execute a download from a server.  I think it's 
> important to enter the same "Save As" dialog programmatically, for 
> client-side generated content.  I don't think this raises the security 
> issues discussed at mozilla, because the user is engaged in the same 
> interaction as they are on any other file download.
>
>
> On 12/18/2011 11:13 PM, Bronislav Klu?ka wrote:
>> Hi,
>>
>> This is quite crucial functionality and sadly not being addressed as 
>> it would seem, because without it application cannot really be 
>> applications (all you can do is to prepare data, upload those data to 
>> server and let user download it manually by clicking somewhere, which 
>> is annoying, unnecessary,  and quite frankly stupid) .
>>
>>
>> but there is a way howto allow user to save file from javascript 
>> without flash
>>
>> http://www.webnt.cz/demos/034_a_download/
>>
>> this demo (the generated files) allows you to download/drag'ndrop 
>> generated file using JS (no flash)
>> it's working in Chrome only at this point
>> FF team is having some security issues I've been discussing with them
>> https://bugzilla.mozilla.org/show_bug.cgi?id=676619
>>
>>
>>
>> B.
>>
>>
>> On 16.12.2011 0:58, David Karger wrote:
>>> It isn't clear to me that a "tag" question can be addressed by an 
>>> "api" answer.   Even if there is an api for saving to file, isn't 
>>> there value to being able to declare your intentions through a tag?  
>>> The <input type=file> tag specifies that a user will be able to 
>>> interact to specify a file through a dialog.  There's absolutely no 
>>> commitment that that file will actually be uploaded or input.  
>>> That's up to the form or the javascript that handles the input.  It 
>>> seems entirely consistent to be able to permit specification of a 
>>> brand new file in that dialog that <input type="file"> is already 
>>> creating.   What some javascript _does_ with the specified file 
>>> might need to be implemented using a filesaver api, but that's 
>>> separate from the declaration of an interaction for specifying the 
>>> file.
>>>
>>> On 12/15/2011 6:45 PM, whatwg-request at lists.whatwg.org wrote:
>>>
>>> On Mon, 15 Aug 2011, David Karger wrote:
>>>> /
>>> />/  Apologies if I'm revisiting old territory.  I've been doing 
>>> work on pure
>>> />/  html/javascript applications that work entirely clientside
>>> />/  (http://projects.csail.mit.edu/exhibit/Dido).  For persistence, 
>>> they
>>> />/  read and write local files.  There's already an<input type="file">
>>> />/  interface for letting the user specify a file to be read.  And 
>>> I can use
>>> />/  the same interface, inappropriately, to let the user overwrite a
>>> />/  preexisting file.  But things get much messier if I want to let 
>>> the user
>>> />/  specify a _new_ file to be written, because the file-open 
>>> dialog doesn't
>>> />/  offer users a way to specify a new filename.  What I'd like to 
>>> be able
>>> />/  to do is specify a tag, or a invoke some javascript method, 
>>> that will
>>> />/  produce the "save file" dialog typical of most systems, with a 
>>> graphical
>>> />/  directory browser but including the option to specify a new 
>>> filename.
>>> />/  This problem isn't unique to me; a discussion on stackoverflow 
>>> appears
>>> />/  at
>>> />/  
>>> http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file
>>> />/  where the proposed solution is to use flash---and that would be an
>>> />/  unfortunate loss of html5 purity.  They also suggest the hack 
>>> of using a
>>> />/  data: url but that has size limitations.
>>> />/
>>> />/  Perhaps<input type="file">  could be given an attribute specifying
>>> />/  whether a new filename is permitted?
>>> /
>>> On Wed, 7 Sep 2011, Eric U wrote:
>>>> /
>>> />/  This sounds like a job for the FileSaver interface.  Currently no
>>> />/  browser implements it, but we at Chrome have been considering 
>>> it.  At
>>> />/  TPAC last year we discussed it a bit in the WebApps WG meeting; 
>>> IIRC we
>>> />/  talked about letting it take a URL instead of or in addition to 
>>> just a
>>> />/  Blob, for more general utility.
>>> />/
>>> />/  I suggest you bring it up on public-webapps@, where that spec 
>>> lives.
>>> />/  
>>> http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver
>>> /
>>> I agree that an API like FileSaver is the right way to do this. Using
>>> <input type=file>  wouldn't really fit well because that's more for
>>> providing data for upload than providing a file for writing.
>>>
>>

-- 

s pozdravem
          Bronislav Klu?ka



http://www.bauglir.com <http://www.bauglir.com>

http://www.bauglir.com
Bronislav.Klucka at bauglir.com  <mailto:Bronislav.Klucka at bauglir.com>

   * webov? aplikace
   * software na zak?zku

Received on Sunday, 18 December 2011 21:35:19 UTC