[dev-servo] NCSU Team Introduction for subsequent steps of form validation issue
Hello, We are a team of four and we will continue the servo issue, Implement HTML5 form validation, from the last NCSU group by Bhavya Bansal. Our group has four teammates: 1. Yuxin Cheng 2. Siyu Huang 3. Xilai Li 4. Zhongcan Xiao We will implement the subsequent steps of the validation process and try to solve the problem. Regards Yuxin Cheng 919 397 1612 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Using IPC channels with Tokio?
Yes. Of course. On Wed, Nov 16, 2016 at 8:16 AM, Eddy Bruel wrote: > For the Servo debugger, now that we've begun landing the Rust interface to > the Debugger API, we can also started working on the next step, which is an > IPC client/server on top of that Rust interface. This IPC server will allow > the main debugger server, which lives in a separate process, to talk to the > debugger API of one or more script threads. > > Since the IPC client/server inherently asynchronous in nature, I was hoping > to implement the client side API with futures. Essentially, for each > synchronous function on the server side, there will be a corresponding > asynchronous function on the client side that returns a future. > > The futures on the client side will typically be resolved when we receive a > message from an IPC channel (which will typically be either a reply to a > pending request, or some kind of notification). For that to work, we need > to be able to hook IPC channels into a Tokio event loop. > > Given the above, I wondered if there is currently any support for using IPC > channels with Tokio? And if not, would it be possible to implement this? > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Servo embedding story & killing mozbrowser
On Mon, Nov 14, 2016 at 9:55 AM, Paul Rouget wrote: > > Would you be interested in using SpiderNode as this runtime? We used in > Positron to run Electron's Node modules and are now experimenting with > using in Firefox to enable WebExtensions to spawn Node child processes. > Using it would give you the Node APIs implemented on top of libuv, plus > third-party APIs available via NPM. > > I'll let Till answer this. I don't know much about what we want for the > runtime. Our focus is on creating a unified developer experience for Servo embedding. With the core embedding API targeting Rust, we're looking into building a lightweight runtime that seamlessly ties into the Rust ecosystem. In particular, I'm working on a Tokio[1]-based runtime that allows mixing of JS and Rust modules. Irrespective of how that experiment turns out, SpiderNode might be very valuable for us. Clearly the NPM ecosystem contains a wealth of functionality; tapping into that would be great. It might be possible to do this without running the core runtime in a libuv event loop. In general I'm very interested in seeing how our groups could collaborate. For example, we should ensure that Paul's embedding API is strictly more expressive than a more generic API. One way to ensure this would be to collaborate on an adapter layer implementing your API on Paul's. I'd see it as a bug in our API if that's not possible. (Though it doesn't necessarily need to be trivial - this wouldn't be an everyday undertaking after all.) And we should sync up periodically so we don't needlessly duplicate effort - I propose we start that with a meeting at the All Hands. [1] https://medium.com/@carllerche/announcing-tokio-df6bb4ddb34 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
