[whatwg] Uploading directories of files

[ddailey]

Rereading comments 1 - 24 of 
https://bugzilla.mozilla.org/show_bug.cgi?id=143220  as cited below, reveals 
to me that I was not the only one in the past 7 years to encounter the many 
use cases (involving client-side access to local images). I was quite 
disappointed when it finally became disabled in all browsers. (circa 2006 in 
IE, I think).

Thanks to David B. for pointing out the history of some of the discussion 
within Mozilla and to Jonas for pointing out the demos of Firefox 3.6 using 
the new file API from http://www.w3.org/TR/FileAPI/ .

It looks like this will address my use cases (including a client-side 
animation studio and client-side image manipulation). Between the various 
proposed methods and canvas, it looks like one will be able to do lots of 
fancy stuff.

One question I have about the FileAPI: should I address it here or contact 
the group responsible at
public-webapps at w3.org ? That is while I see a method for grabbing "blobs" 
consecutive bytes from the image file, what might also be quite handy would 
be the old-fashioned Bit-blit sort of stuff. Specifically, it would be nice 
to deal with an arbitrary sub-rectangle of an image on the screen. 
Currently, I believe (correct me if I'm wrong), to use a clip region in 
either SVG or HTML of an image displayed in the browser (from a local or 
remote source), one has to essentially create a new version of the image 
(see either 
http://srufaculty.sru.edu/david.dailey/javascript/weave/weaver.htm or 
http://srufaculty.sru.edu/david.dailey/svg/clips2.svg ) to overlay clips. 
This is expensive in RAM and performance as the data in 
http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.html 
would indicate.

By being able to sample, for example a 20 pixel by 20 pixel sub-image of a 
rectangle as its own bitmap, would be considerably more efficient than the 
ways I have been doing this sort of thing. But if I understand the BLOB, it 
would be consecutive bytes from the actual file itself, as compressed in 
GIF, JPEG or PNG  (or SVG???) format?? That would be useful for certain 
kinds of image "analysis," but for higher level image "manipulation," having 
to deal with all those bytes in JavaScript would be much slower it seems 
than something implemented close to the onscreen (or offscreen) drawing.

I like the direction this is going though!

cheers
David

----- Original Message ----- 
From: "L. David Baron" <dbaron at dbaron.org>
To: "Jeremy Orlow" <jorlow at chromium.org>
Cc: "Markus Ernst" <derernst at gmx.ch>; "whatwg" <whatwg at whatwg.org>
Sent: Sunday, December 13, 2009 3:01 AM
Subject: Re: [whatwg] Uploading directories of files


> On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote:
>> But regardless.....I don't think you could argue that having _some_ path
>> information is worse than _none_, right?
>
> Many of those who commented in
> https://bugzilla.mozilla.org/show_bug.cgi?id=143220 and its
> duplicates would disagree.  Users may not expect the act of
> uploading a file to give the Web site details of their file system
> structure.  There also seems to be some concern that those details
> may provide information useful to an attacker.
>
> -David
>
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
>
>