Hi, I have finished the first step “Draft" in the GSoC site and wonder if you can see my draft proposal now. Welcome any comments!
Beyond that, I have some more related questions: 1. I assume that this method https://github.com/servo/servo/blob/master/components/script/dom/htmlinputelement.rs#L858 is where we should open the dialog and get the filenames, right? And there are also much TODOs left in htmlinputelement.rs, I think they are necessary for this project. 2. What should we do if a file is *really* big? If we are just reading it locally rather than sending it over network, I think a partial reading might be possible by controlling precisely the range in `std::io::Read`; If we send it over the network, I remember the spec talks about chunking and streaming the data — but is this related to this project at all? 3. About Blob URL, I image that the response doesn’t really contain anything in its body — the URL itself is used to dereference the object. So the Blob URL Store etc. are global state of UA, and is shared across the windows. Is my understanding right? 4. I mentioned the possibility of using KISS-UI as dialog for selecting a file, but it looks a bit heavyweight. What is your idea about this? And what is the rough plan about integration of UI components into the Servo now? Thanks a lot - Zhen > On 16 Mar 2016, at 4:08 AM, Manish Goregaokar <manishea...@gmail.com> wrote: > > > > -Manish Goregaokar > > On Wed, Mar 16, 2016 at 1:37 AM, Manish Goregaokar <manishea...@gmail.com > <mailto:manishea...@gmail.com>> wrote: > > On Tue, Mar 15, 2016 at 3:13 PM, Zhen Zhang <izgz...@gmail.com > <mailto:izgz...@gmail.com>> wrote: > > 1. About FileList API, It is said to be *at risk* to be replaced by Array. > <https://w3c.github.io/FileAPI/#filelist-section> Do we have to take this > into consideration? > > We still need to implement it, since the `files` attribute for form inputs is > quite useful and the spec hasn't yet changed to make it an array. So no, not > really, though if you'd like to not implement this and spend more time > working on something else that's totally fine. > > 2. Although I read nearly everything I can get from input element, form > element, Blob interface …, but I am still having a hard time trying to > understand when a file on disk got read into the memory and used to construct > a Blob object. > > See https://w3c.github.io/FileAPI/#blob > <https://w3c.github.io/FileAPI/#blob>, especially the first three lines, as > well as the first two lines and the blue box here > <https://w3c.github.io/FileAPI/#file>. Basically, Blobs/Files can be > in-memory blobs (our current Blob implementation handles this), but they can > also refer to on-disk blobs which have not been read into memory. So, if a > blob is to be constructed from on-disk data, the disk data is not read into > memory at all, instead the blob will just contain an open file descriptor and > a byte range, or something similar. If the file changes in the meantime, > errors might be thrown <https://w3c.github.io/FileAPI/#ErrorAndException> > (though I don't think this happens in practice except for permissions errors). > > You can test this by creating a simple HTML page with a file upload, and > verifying that if the file changes in the filesystem, reading the File object > (accessed via input_element.files[0], read via URL.createBlobURI) before and > after the change will give different results even if the file object was not > touched on the javascript side. > > (interestingly, blobs referring to on-disk data pin their `size` and > `lastModified` fields to the values on creation, and this isn't updated at > all even though an access of the data will get you up to date data) > > 3. Drag & Drop <http://www.sitepoint.com/html5-file-drag-and-drop/> of > selecting files from file system — This looks related, but I don’t know if we > should pay more attention to it. > > It's possible to do. However, this first needs regular dragdrop event > support, which might not be as easy to implement. It additionally will need > handling of file dragdrop in Glutin. This might take up a lot more time than > we want it to. > > 4. What is the idea behind using GenerationId > <https://doc.servo.org/script/dom/htmlformelement/struct.GenerationId.html>? > I am a bit confused because there is little doc about it. > > It takes part in planned navigation > <https://html.spec.whatwg.org/multipage/#planned-navigation>. This basically > handles cases where a form submit button is clicked once, but before the page > navigates you quickly change one of the inputs and submit again. Each > submission event is queued as part of "planned navigation", but the first > submission event will have an outdated generation id (which is bumped every > time the form is submitted), and only the second navigation event will happen. > > Thanks, > -Manish Goregaokar > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
