On 3.2.2012 8:24, Charles Pritchard wrote:
On 2/2/12 11:08 PM, Bronislav Klučka wrote:
On 3.2.2012 7:51, Charles Pritchard wrote:
I see no reason why an author should expect to stash 100MB of
objects into createObjectURL, nor any reason why a UA could not
manage 100MB for the application lifetime; the user can certainly be
informed, as they are with other APIs, if the limit has gone beyond
what the UA is comfortable with. That's always useful for
debugging/development -- when infinite loops are a normal part of
the web experience.
Well how about 1GB video :D or 100 high resolution images?
But as you say.... there's no reason, why desktop application
(browser) should have any problem with it...
And yes... there may be some disk space problems on rare cases, but
such problems can appear in any regular usage of any program (well,
there's simply no space left)...
We're going to be treating that video as a media stream via Blob URL.
Which is a good point -- it's going to be a Blob url of some sort but
it is a special case.
That 1GB video is not getting loaded into RAM all at once.
A video blob is going to look like some cross of:
http://www.w3.org/TR/streamproc/#media-element-extensions
http://dev.w3.org/2011/webrtc/editor/webrtc.html
http://dev.w3.org/2011/webrtc/editor/webrtc.html#blobcallback
It's gonna be messy!
Remember, we've got createObjectURL(File) as well, and the mess that
can cause, as recently discussed.
The underlying File data could disappear from the file system at any time
That in mind, my focus is on <img>.
And with 100 high res images, believe me: I'm using thumbnails.
Not only that, I'm packing 8 thumbnails into each blob/file.
So with 100 high res images, we're talking about 12 blobs, less than
60 megs.
A lot less now that JPEG is widely supported for Canvas.
-Charles
I've already mentioned somewhere before I hope Blob would be descendant
of stream, I have no problem with reducing this issue to more generic
one (stream).
1GB video would not be loaded to RAM, why would it? I see no point of
doing that, as long as one can seek in underlying stream, there's no
point. I was referring to "why an author should expect to stash 100MB of
objects into createObjectURL", why not? if it's all cached on disc.
author should not expect to have 3GB data in memory at once, but why
would he/she? That is nothing one should be concern with.
"The underlying File data could disappear from the file system at any time"
Well.. they should not while they are managed by browser. And deleting
the content by user (other application)? Well, I can go and simply
delete all images on my server... and webpages would be displaying
nothing for normal pages, server scripts working with such files could
have problem. User can have image library desktop program displaying 20
images, then go, delete 15 of them from disk (while app is runnig) and
trying to access those using this desktop program... problem for app.
Special cases? Yes. Something new and unheard of? No... Programmer
should be able to handle those.
We can always have triad createObjectUrl, revokeObjectUrl and bool
checkObjectUrl(DOMString aUrl).
Brona
