Great thanks! About proposal draft, I have add the link to my experimental nfd binding (still not working but in progress :D), as well as new format for “planned stages”. Welcome comments
- Zhen > On 18 Mar 2016, at 3:42 AM, Manish Goregaokar <manishea...@gmail.com> wrote: > > > On Wed, Mar 16, 2016 at 6:50 PM, Zhen Zhang <izgz...@gmail.com > <mailto:izgz...@gmail.com>> wrote: > > I have finished the first step “Draft" in the GSoC site and wonder if you can > see my draft proposal now. Welcome any comments! > > > The draft looks good. I left some comments inline; let me know if you have > any questions? > > 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 > > <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? > > Yep! > > > And there are also much TODOs left in htmlinputelement.rs > <http://htmlinputelement.rs/>, I think they are necessary for this project. > > Most of them, not really. The ones which reference files, yes. > > > <https://github.com/servo/servo/blob/7a9dc577617b442ff0fe07eaa683207234c519ee/components/script/dom/htmlinputelement.rs#L376> > 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? > > Yes, we would want to chunk/stream the data somehow. It's not strictly > necessary for this project, but it would be nice to be able to handle large > files without bumping up Servo's memory usage. > > It might even be possible to use sendfile > <http://man7.org/linux/man-pages/man2/sendfile.2.html> to do this on > linux/osx, since the file memory is directly copied to the network without > touching userspace. However, this might involve some hairy interactions with > hyper; definitely not something that is a requirement. There's also the > multipart/form-data boundary that needs to be handled properly. > > > The chunking/streaming mentioned in the spec are from use via the DOM (i.e. > when Javascript tries to read a file). When a form with files is submitted, > the spec doesn't talk in terms of File objects, it just talks of files. > XHR/Fetch do something similar. > > > > 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? > > Yes, this is true. > > 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? > > It looks like KISS-UI needs your application to be built in KISS-UI to work, > I'm not sure if it provides a standalone function for a file select popup. > You're welcome to investigate, though :) > > There's no real plan for UI components. I imagine we'd end up using a > cross-platform library and somehow getting it to work through our opengl. > > > > > -Manish Goregaokar _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
