Re: [dev-servo] Servo Project NCSU team
On 09.03.2018 19:52, Patrick Poggi wrote: Hello, Bhanu and I are both NCSU student that will be working on the http archive support project.( https://github.com/servo/servo/wiki/HTTP-archive-support-project) At the moment, we are unsure of how to proceed with the project. Any suggestions or direction would be helpful, as this is our first time contributing to an open-source project. Isn't that just writing detailed log files ? I'd seriously suggest *NOT* writing HAR files directly, *NOR* collecting all records in some central buffer - introduces all sorts of concurrency problems (not even speaking of multiprocess issues) as well as inter- dependencie of many subsystems, which in turn requires much lock/wait issues, therefore distorts the measurement itself. Instead just add simplicistic logging to various areas you're interested in (please make it compile-time configurable - at least until we have an kprobes-alike runtime code-path configuration ...) and take care that the log-writing is as fast and simple and non-intrusive as possible. Just write out the few bits (w/ exact timestamps), standard formats, etc (could also be arch-specific binary encoding). Pulling things together into formats like har, human-readable logs, etc, should be done separately - that code should be available as a separate command line program (one might wanna run this on separate machines). The approach described in the Wiki page is unnecessarily complex and risks adding a lot latency and subtle bugs. I'm opposed to that. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] embedding as a separate program/process [WAS: Dropping CEF support?]
On 07.02.2018 15:41, Paul Rouget wrote: Is that really better than a entirely different process for everything except the rendering part? Yes, it's much easier to maintain and integrate, eg. we don't even have to think about all the shared library problems. Because Servo is designed to work that way, and it's not to hard to embed. All you need is a gl surface, which is possible on linux, windows, mac, android, and ios. Unlike reparenting. The whole GL context management is complex enough (due to the horrible design of OGL API) - I'd rather not open that can of worms in usual applications. OTOH, window embedding should work on most platforms (not idea about recent windows, as I didn't touch it for aeons, but back on win32 / nt, I did it myself - just forgot how that worked). For the really esoteric legacy stuff like android, we still could have a statically linked application (shared libraries are pretty impractical there - until somebody really had too much spare time and fixes that code monster. (I'd rather build a completely fresh mobile/handheld distro instead - much more efficent than working around that ill designed mess forever, but that's a whole different story ...) If you want to use servo+tabbed, I think it's already possible. If not, let me know, I can help make that happen. Well, just putting servo windows into tabbed is the easy part. But building your own complete UI, there're still lots of interfaces missing. We'd need access to all the operations we already have for the (shared library-)embedding, eg. tracking history, call URLs and scripts, filter traffic, manage certs and other security stuff, script injection, DOM manipulations, etc. Note: I certainly do not want to have some (in-process) extension system like FF or chrome have. Instead attach external service agents (which run as separate processes). --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Standalone NDK concerns?
On 07.03.2018 17:15, Nathan Froyd wrote: FWIW, the Android team is planning on making standalone toolchains obsolete in the relatively near future (the roadmap says later this year): https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#make-standalone-toolchains-obsolete Actually, this should have been done aeons ago - and the whole idea of all these "sdk"'s is pretty ridiculous. Instead there should be an clean separation between individual packages (incl. kernel, bootloader, etc), toolchains (compiler, binutils, ...) and the distro buildsystem system (eg. debuild, buildd, ...) and target- as well as dist-specific confguration. That's pretty much what we're doing w/ debian world as well es embedded kits like ptxdist. For an android-alike system that primarily means: * different c-library (which nowadays wouldn't be necessary anymore, as non-ancient mobile handsets are strong enough for running plain glibc+friends) ... historically there had been a strong connection between libc and gcc (had to be compiled together, to fit each other), but that also had been lifted long ago (IIRC clang never had that problem) * customized kernel, bootloader, image layouts, etc (basically what ptxdist calls the platform configuration) * additional java->dalvik compiler All the rest is just usual sw packages ... pretty boring from build engineering pov. Unfortunately, Google doesn't wan't an simple and straightforward, easily understandable and customizable system. (it's really time for creating an own mobile/handheld distro) For servo, we'd have to add the rust toolchain (configured for the particular target - within an arch, it should be pretty generic). It's long ago since I touched android the last time, but IMHO, the first step should be integrating rust into several distros - up to the esoteric ones like android - then treat servo as just yet another library package. Actually, servo shouldn't be a library, but a dedicated (server) application, which the integrating application just talks to, but doesn't link against (the Plan9 / suckless approach). I did some experiments in that direction several months ago, but yet lacking time for deeper involvement. One thing's absolutely clear for me: give up the whole concept of SDKs as such. It never fits well and just horrible to maintain. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Servo Project NCSU team
Hi Patrick! What parts of the initial steps are giving you trouble? Cheers, Josh On 3/9/18 1:52 PM, Patrick Poggi wrote: Hello, Bhanu and I are both NCSU student that will be working on the http archive support project.( https://github.com/servo/servo/wiki/HTTP-archive-support-project) At the moment, we are unsure of how to proceed with the project. Any suggestions or direction would be helpful, as this is our first time contributing to an open-source project. Thank you. Bhanu and Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] NCSU: CSC 517 Project- Random web content generator
Hello, We (Abhay Soni, aso...@ncsu.edu; Pranshu Sinha, psi...@ncsu.edu; Aayushi Agrawal, agr...@ncsu.edu) are students at NCSU currently assigned to this project. We wanted to notify you before we start working on the project. Let us know about any resources you think can help us work on the project. Thanks! -- Abhay Soni, North Carolina State University ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Servo Project NCSU team
Hello, Bhanu and I are both NCSU student that will be working on the http archive support project.( https://github.com/servo/servo/wiki/HTTP-archive-support-project) At the moment, we are unsure of how to proceed with the project. Any suggestions or direction would be helpful, as this is our first time contributing to an open-source project. Thank you. Bhanu and Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
