W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: File descriptors

From: Eric Uhrhane <ericu@google.com>
Date: Mon, 4 Oct 2010 08:34:24 -0700
Message-ID: <AANLkTikTXCt8w3GP0dCV4muvMSXiGN+U8t2_F8zXRvq7@mail.gmail.com>
To: lmarcetic@foi.hr
Cc: public-webapps@w3.org

     Have you looked at the filesystem spec [1]?  It might have some
of the features you're looking for.  It won't let you read arbitrary
local files directly, for security reasons, but if you generate or
download the files yourself, or if the user selects them for you, you
have full access to them.  Incidentally, you don't have to read an
entire File or Blob into memory at once if you don't want to; you can
use slice() to pull out just a part of it at a time.


[1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html

2010/10/4  <lmarcetic@foi.hr>:
> Dear people of W3C,
> My name is Luka Marčetić, I am a student at Faculty of Organization and
> Informatics in Croatia.
> This, I guess, would qualify as a feature request. Your FileAPI draft is a
> step in the direction I want to take, but it's not quite there yet. I need
> something to allow me to:
>  * read local files,
>  * show them in web documents, and
>  * manipulate them
> FileAPI does the first thing, and partly the third one. The problem is
> that it, as I understand it, loads the complete file into memory
> (readAsBinaryString) which is inconvenient for big files, such as video.
> Expanding on the video example, DataURI scheme fails for the same reason.
> Being designed for addressing the second issue, it falls short to meet
> (my) real world needs. Finally, the file:// URI also needs mentioning
> here. It would be able to solve the second issue entirely, but is of
> nearly no use, being blocked by default by most or all browsers. I can't
> expect my future users to fiddle with browser configuration just to get my
> website "working".
> To solve these issues, I would like to propose C-like file descriptors to
> be used coupled with a new file descriptor URI scheme. It would allow me
> to, for example, let the user choose a video file he wants to edit, and
> then show it in a <video> tag, like this:
> <video src="fd://file" controls="controls"></video>
> Lastly, a file manipulation mechanism would be useful for fully addressing
> the last of the three issues. File API mechanism is the only one of the
> three mentioned tools that partially addresses it. But it does so in a
> manner that simply necessitates its (imo) flaw. In my opinion, the correct
> way to deal with this would be a fread function, resembling more the PHP's
> fread function than C's counterpart (tellp/tellg, and fwrite implied).
> This modification would, I suppose, be done to the FileReader object:
> I hope you will see the merit of this. Thank you for your attention,
> --Luka Marčetić
Received on Monday, 4 October 2010 15:35:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC