231–240 of 246 posts
While there are still lot of work to be done on servo. I wonder if other browser engine be able to benefits from the research mozilla has done. Like Webkit / Blink. Or will this require some major rewrite?
Earlier quoted context omitted.
> SIP and the IETF to some extent encourages this with Postel's Law, telling implementors they should guess what the intention of the message is. We need less of VB's On Error Resume Next and more panic-abort type functionality. I don't think it's as clear-cut as that. I think the main thing is error handling must be defined: it doesn't matter whether it's panic-abort or whether it's defined how to deal with any stre…
Well the error handling is defined. Return a 400 Bad Request. Except implementors are encouraged to try to avoid that if they can make guesses.
RFC 7230, for example, has error handling sometimes as SHOULD return 400 Bad Request and sometimes as MUST return 400 Bad Request. But that only applies to servers and proxies parsing requests, which are really the relatively well-implemented part of HTTP. (The vast majority come from browsers, which are always syntactically valid; responses can come from arbitrary CGI scripts and you get all kinds of syntactic nonsense there.) Sadly, there's comparatively few normative requirements when it comes to parsing responses, even ones which are needed for backwards compatibility (at what point do you conclude you're just talking to an HTTP/0.9 server?).
It's amazing to see actual effort taking place to build a new browser engine from scratch. I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. The existing engines have it…
> I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. Compared to KHTML, Webkit and Blink were pretty much 5 or more whole new projects on top of it. And even the latest IE is hugely rewritten compared to Trident.
Is there an article somewhere comparing how Servo and Chromium threaded compositing differ? I guess there is some work on Chromium side to render pages using multiple threads, but I couldn't find more information and how it compares to Servo's mechanism.
Retrofitting multithreaded, off-main-thread restyle/layout/painting onto an existing engine is an enormous undertaking, almost on the level of rewriting from scratch. This is much of the reason why Servo's rendering is from scratch, in fact.
Earlier quoted context omitted.
Hey, stop that. This topic is about nightly builds and contributing to open source project. Linux is great for that because it made by developers and for developers, and not because it has a polished UI/UX. Linux UI is rough. Accept that.
This specific branch was to ask for an ETA for the Windows Nightly, and you hijacked it. I advised you to refrain from hijacking it and you began spitting anti-Windows nonsense like a freshman who drank the Linux cool-aid for the first time. This is not the place to discuss about operating systems, and people expect from you to respect their preference. Linux has its technical merits, and because of them it is the mo…
Earlier quoted context omitted.
There have certainly been spec bugs that could be found from a formal specification, some of which are security related (most of the TLS bugs found by miTLS have been protocol bugs simply found as a result of encoding much of the semantics formally). That said, while I certainly have a fondness for formal specifications, I also always end up feeling like they have a lot of downsides. They're often very verbose and ha…
Re specs downsides The wisdom from old days was to use relatively, simple, formal languages that were easy to train people on and use. B, Z, and TLA had good results plus lasted over time. The other thing was to do English spec, formal spec, and code side-by-side with each team looking for inconsistencies. The developers usually picked up the basics of the technique rather quickly but at least one specialist was alwa…
From when I've considered trying to formalise parts of the platform before, some of the things that often get hit very quickly are the fact that most of the web platform is defined in terms of sequences of Unicode code points, and ultimately any formalisation is going to have to deal with that (be it some complex parser—like HTML—or some simple validation of it matching a regular grammar). It has always seemed to me that to get much advantage you need to be able to programmatically assert statements about it (including, most obviously, pre-conditions are satisfied at all call-sites), but once you've gone from 2^256 to 2^1114112 characters you end up with such massive state explosion that even many symbolic tools start to struggle quickly.
Now, maybe I've tried using the wrong tools, or maybe I'm structuring things wrong, but it'd be nice to have some way to do this.
Earlier quoted context omitted.
Re specs downsides The wisdom from old days was to use relatively, simple, formal languages that were easy to train people on and use. B, Z, and TLA had good results plus lasted over time. The other thing was to do English spec, formal spec, and code side-by-side with each team looking for inconsistencies. The developers usually picked up the basics of the technique rather quickly but at least one specialist was alwa…
(As a disclaimer, for some context, I have only relatively passing experience with Z, and the majority of formal modelling of specs I've done is using CSP.) From when I've considered trying to formalise parts of the platform before, some of the things that often get hit very quickly are the fact that most of the web platform is defined in terms of sequences of Unicode code points, and ultimately any formalisation is…
Earlier quoted context omitted.
(As a disclaimer, for some context, I have only relatively passing experience with Z, and the majority of formal modelling of specs I've done is using CSP.) From when I've considered trying to formalise parts of the platform before, some of the things that often get hit very quickly are the fact that most of the web platform is defined in terms of sequences of Unicode code points, and ultimately any formalisation is…
Hmm. That's unusual situation. I've seen descriptions that sound similar in B data validation. For now, I'll just make a note of this comment to bring up when I next bump into formal methodists that might have answers.
How do you actually open the developer console? ;)
If you start servo with the devtools port on, you can use the Firefox tools to get a remote console. This may or may not be working well at the moment. The JS console.log stuff will get output to stdout or stderr when you run as well. There are discussions underway about how to bring in other tools, and how to get stuff like this into Servo or browser.html itself.