latency. Many PCs built today have 2 trhru 4GB of real RAM, so they
appear to have 4 to 8GB providing lots of headroom to manage somehow
big files. It the files to handle were bigger, then it's the
developer's responsibility to manage the issue, for example telling
the user not to upload a file.
It should not a making a copy vs. using the original data issue.
These are different scenarios and which to use should be up to the
developer to knows the requirements and the environment of her
application.
In the original RFC1867 specification if the user uploaded a very big
file she had to wait for ages for the whole file to upload before
getting an error message. The File API comes to the rescue, allowing
the UA to say so before the upload.
** The scenario I'm working in
My scenario for the blob functionality is related to image uploading.
The UI gets a bunch of files containing images of various sizes.
Somehow the client (UA) resizes them to fit some web application
limits before the upload like limiting width to 800px and lowering
quality so the size is below 100K, and to do so it stores each image
in a blob.
The user is looking at the image in the UI during this process and she
does not expect it to change due to local file action. If she wants a
new version of some image then she reloads them. For example she
modifies the image colors and saves a new version.
** This is the only chance to make changes to the API
Changing the API should not be a bounding constraint at this stage.
Joshua Bloch, regarded as the most important API designer says that
Public APIs are forever - one chance to get it right in this
context: http://lcsd05.cs.tamu.edu/slides/keynote.pdf
If it is possible to change it for better it must be done before it's
too late. Else millions of developers in the future will lose parts of
their lives struggling against definitions like the DOM differences
that literally swallowed entire lives in terms of time spent doing
avoidable work. Bloch publicly shares his knowledge about API design,
the documents are findable searching for Joshua Bloch API design. I
apologize if this information is too obvious for someone, I bring it
here because I consider it's valuable to keep it in mind, al least for
me.
For example JB encourages doing the design based in user needs and use
cases, and I was unable to find any formal such document (I recognize
that I used limited time in my search). He says Gather
Requirements–with a Healthy Degree of Skepticism, meaning that the
users MAY propose solutions but that the last work MUST come from a
knowledgeable professional. In this thread I didn't see references to
users, sauve for two postings by Dmitry.
In short:
- Trash the mutating blob,
- lock the file when opening it (by default) and release it upon close,
- let the developer decide about copying the file in memory or slowly
read it and feed it to the upload,
- let's not design for technological limitations, and
- let's make it right at the first and only attempt.
Respectfully,
--
Juan Lanus
Globant
