File descriptors

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 12:19:13 UTC