That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services.
I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and that mechanism can be understood by client software and resolution APIs, then I don't see any reason not to allow it.
The salient distinction from my perspective is traffic within a specific host, and traffic that traverses the network. If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)
I also find it curious that this draft allows only address queries (presumably A and AAAA) under .localhost. I'd like to know the rationale for that restriction. For example, there may well be applications that only use SRV records.
"If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)"
Currently where it says "an IP loopback addresses", it may be worth saying something like "any of the IP loopback addresses for the device".
I agree that technically "an IP loopback address" ought to be sufficient, but I have also found it is a very common belief, probably even the majority belief, among people who use networking that "127.0.0.1" is the one and only loopback address. (I've lost count of the systems I've slightly broken just by feeding them 127.1.1.1 or equivalent.) I'm sure people who are the sort to read and write standards know better, but since it doesn't hurt the standard itself to emphasize the point, perhaps it's worth it.
Hey, thanks for the considered reply. I rustled up alternative language you might consider for section 3.1 paragraph 1:
"Name resolution APIs and libraries MUST recognize localhost names as special, and MUST always return a unicast address that cause the node to send an IP datagram to itself."
This deliberately echoes the language of RFC4291 and RFC6890 when defining loopbacks. Can I also suggest revising references, looks like RFC5735 has been obsoleted by RFC6890.
Overall I think this draft is a helpful clarification, thanks for creating it!
Does a page's CSP break your extension in Chrome Canary? We've done quite a bit of work to allow extensions to transparently bypass a page's policy, and I'd much prefer to fix the bugs in Chrome than for you to kill a page's policy via the WebRequest API.
I'd very much appreciate it if you could point me at things that aren't working in Canary. :)
The user agent string is, for the moment, remaining exactly the same format. For better or worse, all those crufty bits are currently necessary for compatibility with sites doing a poor job of sniffing out functionality.
My expectation is that we'll be posting more design docs to chromium.org more frequently. The best way to stay on top of that will be to join the blink-dev group (https://groups.google.com/a/chromium.org/forum/?fromgroups#!...) which will be ramping up shortly.
4. WebKit and Chromium have historically had differing opinions regarding what makes a "good" comment. I think you can expect Blink's code to tend more and more towards Chromium-style as time goes on, but it's not going to happen overnight.
5. ~5 million lines of code that we don't currently compile or run in Chromium. That's a bit, but it won't have much effect on the binary size.
6. Short term, not much will change. Longer term, a few things will probably happen: for instance, the widget tree will likely be removed, and we'll likely be able to step back and reevaluate some changes in light of that.
I mentioned above that the last time I measured (late 2012) the entire mozilla-central repository it was 4.488 million lines of code. How many lines is Chromium? How on earth can you be removing 5 million LOC?
WebKit and Chromium are different repositories, and point to each other via a "DEPS" (dependencies) file. We roll new revisions of WebKit into Chromium regularly, and call the process of diagnosing and fixing problems with the rolls "Gardening": http://www.chromium.org/developers/how-tos/webkit-gardening is a good reference.
You mean having full-time engineers handling merge conflicts / upstream breakage / regressions / running test suites? In anything sufficiently large, that becomes a major issue inevitably.
Almost any project worth its salt has someone doing testing. But it is really time consuming.
Also: these sorts of deep technical questions would be great for tomorrow's hangout: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer whatever you can throw at them. Add questions to the Moderator at: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&....
It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc.
Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run with, Apple created its own framework. That had advantages and disadvantages.
More generally, I'd point to the Content layer as a better integration point: Opera, for instance, is building on top of our multi-process architecture successfully. Chromium Embedded Framework (https://code.google.com/p/chromiumembedded/) is another example of how other projects can leverage the work we've done.
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.
Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.
At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.)
Writing our own seemed like the least bad approach.
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.
I'd also add that I disagree with Mike about the architectures being really different. In fact, they are quite similar in broad strokes, but with many differences in details (and with the significant difference that the Chromium model isn't in WebKit per se).
I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR
We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon.
I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement.
It is true that when we announced our effort, it came with a rough working prototype and not just an empty directory. Basically because we did not know if we could do it until we tried.
BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.
Google had the right to make their choices and we had the right to make ours.
>We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon.
Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective.
>BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.
I don't interpret Mike's comments that way. Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity. I'm comfortable that the divergence was simply a result of different needs. I just don't see how it could be presented as something malicious or anti-collaborative.
>> We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon.
> Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective.
Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks.
> Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity.
It had nothing to do with SFI (which wasn't brought up at the time) or complexity. It was for the reasons I stated upthread.
>Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks.
The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work.
>It had nothing to do with SFI (which wasn't brought up at the time) or complexity. It was for the reasons I stated upthread.
I still don't get what that reason is supposed to be. Regardless, the resulting WebKit2 design was clearly incompatible with the existing Chrome architecture. And the fact that they were continuing to diverge and place a burden on both projects was a clear problem. This was raised repeatedly, but never seemed to receive any serious consideration.
My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting.
I regret that this thread has turned into such a back-and-forth. It's not my goal to detract from the Blink announcement. I feel like it would be rude to leave you hanging on mid-thread. However, I feel like:
(a) You are trying to argue with my version of specific events where I was present in person and you (as far as I recall) were not.
(b) You are trying to argue with my stated motivations for decisions that I was part of and you were not.
(c) You seem to want to assign blame.
Maybe my impressions are wrong. But given this, I find it hard to reply in a way that would be constructive and would not further escalate. I hope you will forgive me for not debating about it further.
Yeah, I didn't intend this to turn into a back and forth. I think we both had similar intentions, but from different perspectives and with different first-hand information that may not be well communicated. I agree that it's best to leave it be from here. I think both of us and our respective projects bear no ill will and desire the best for the Web as a whole, despite differences in how exactly to get there.
A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task.
In light of this, your initial "if Google had only upstreamed their multiprocess support...we almost surely" and reiterations on this point within the thread do seem a bit like PR sleight of hand, since out of context it implies willingness to do so was the only issue on their part.
1) The answer wasn't "we'd like to do this but we're super busy right now, how about later" or "that's super complicated, will you guys put in a lot of the effort". It was a pretty direct no. We would have been willing to do much of the work.
2) My recollection is that we talked about it around a year after Chrome was released.
Chrome Beta release date: September 2, 2008
Date of WebKit2 announcement: Thu Apr 8, 2010 (after <1 year of development)
I don't have records of the meetings where we walked though.
3) Does the reason for saying no affect whether our choice to make our own thing was reasonable?
With regards to 3), yes it does affect it since a "flexible/malleable no" is an altogether different constraint from a "solid no", so the solution would be measured against a different yardstick in the former case. Pressing on with your own thing in the interests of time to market (and thereby further cementing the more mature implementation not being integrated) in that scenario does strike me as less than ideal/short-sighted.
This is somewhat moot with 1) and 2) being the case (or at the very least strongly perceived to be the case on your side). At any rate neither side being able to settle on a single version of events signals a communication problem, which makes the whole value of this hypothetical joint undertaking fuzzy anyway.
The way I read it, they didn't want to integrate until they got an official 'yes' (quote: 'our choices were to do a hostile fork of Chromium into the WebKit tree').
Do you actually know what you pretend to know, or are you holding a grudge against Apple for an old transgression with KHTML that they've since done did a great deal of work to put right?
Hi Maciej. Sorry if my comments read as though I was implying that you were wrong or bullheaded to choose WebKit2. That wasn't my intention; there are of course good technical arguments for choosing either architecture, and I'll choose my words more carefully next time the question comes up.
Thanks, Mike. And sorry also if my reply was too lengthy or pedantic or otherwise out of place. I feel bad for getting into a back-and-forth about this.
I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.
If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions.
To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.
A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.
Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.
You could see the history between xMule and aMule for a hostile fork. Or the history between ffmpeg and libav, where some contributors where denied access to the repo.
I always believed (hoped) you guys would never be corrupted and do the right thing for the world and not be swayed by organizational affinities / commercial gains.
You have a greater responsibility than to your company or country to keep the web open.
Think on that before you have a further public 'kiddy debate' on she said / he said and throwing the rattle out of the pram.
A stunningly reductive question deserves to be responded to in kind :)
I don't know much of this history, but was integrating Chrome's processor model into WebKit feasible at the time that WebKit2 was built? What were the reasons for not doing so?
Generally, I think WebKit2 and Chromium simply disagree about where to hook into the platform, and what the responsibilities of the embedder should be. The description at http://trac.webkit.org/wiki/WebKit2 is written from Apple's point of view, but I think it's broadly fair.
The position we're taking is that the Content layer (in Chromium) is the right place to hook into the system: http://www.chromium.org/developers/content-module That's where we've drawn the boundary between the embeddable bits and the Chrome and browser-specific bits.
Regarding the history, I'd suggest adding some questions to the Moderator for tomorrow's video Q/A: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)
The Chromium team will be running a Hangout tomorrow to answer any questions that pop up. Hit this Moderator page to ask whatever's on your mind: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&...
I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and that mechanism can be understood by client software and resolution APIs, then I don't see any reason not to allow it.
The salient distinction from my perspective is traffic within a specific host, and traffic that traverses the network. If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)
I also find it curious that this draft allows only address queries (presumably A and AAAA) under .localhost. I'd like to know the rationale for that restriction. For example, there may well be applications that only use SRV records.
https://twitter.com/dbrower/status/781001487157719040 raises similar concerns. The rationale is simple: I wanted to make the smallest change possible to RFC6761, and item 3 of https://tools.ietf.org/html/rfc6761#section-6.3 already contains the address query restriction.
It's probably reasonable to reconsider it, that's just a larger change than the one I was specifically trying to make. :)