OK. Google announced big news and Opera did also.
- Google Forks WebKit and Launched Blink, A New Rendering Engine That Will Soon Power Chrome and Chrome OS
- Google forks WebKit with new ‘Blink’ rendering engine for Chrome
Although it’s reasonable decision after I read it, I had to think this way also. “Well, the biggest contributor to WebKit is now Google, not Apple. So, why do we help once-friend-but-now-enemy company by contributing WebKit which also propells our enemy’s browser?”
Well, having very different architecture under same source code is very difficult to manage. Also, for many years, in the world of personal computing, threading model prevailed multiprocess model for many reasons. Still, writing very robust server software called daemon on Unix has been benefited when multi-process model is adopted. However, due to simplicity of “thinking” and cheap price of Windows machines, on personal computers, multiprocess model has been very popular.
It’s very interesting to see Google chose multi-process model. If a person or a company is serious about performance and reliability, it’s very reasonable to consider the model.
However, why I smell some politics and business strategy here….
Surely for Google, to spur HTML rendering engine not just for their Chrome browser but also Chrome OS, they should have sought reliable and fast architecture. So, technologically I understand their decision. Merging back the source code with multiprocess in mind could be slow and could need to be extra careful. However, won’t it be possible to persuade others also to adopt multi-process model? Are there some OS or CPUs which are difficult to support it? No. Probably there can be architecture and philosophical resistance for adopting the model. Whether to fork a process which handles GUI or not can be interesting decision point. Well, if they fork a process by windows, then it can be easier. What I mean is they don’t need to fork() only a process which doesn’t have GUI code. However, from each platform OS’s point of view, they may confront interesting issues. Although the forked GUI process is OK to be seen as separate process in task manager or “ps”, to users’ eyes it would look awkward if it suddenly displays two separate instance of the same program on the “Window” bar on Windos or “Dock” on a Mac.
On Windows, especially in the era of Windows 3.1, each Windows of a process/thread can have their own visual instance on the winddows bar. So, it can be Ok on Windows. But how about on Mac? Shouldn’t it be better if OS X displays one icon on its dock and “forked” processes are all managed visually under that “one” icon?
If forking GUI process is awkward, then it’s easy policy-wise to fork non-GUI process.
However, there are some issues remained like “how to roll-back or re-initiate some work expected by forking multiple process and gathering results from them if one or some of the processes crash?”
Well.. in the world of CS field,those are already thought for many years. So, there will be easy to adopt “policy” or some people can think of their own. If they decide to fork non-GUI chores, I don’t expect many visual accommodation on many OS platforms.
Anyway, they have to determine those kind of stuffs. And.. will it be really hard? Yeah.. for individual programmers, it can be hard. But you know, there has been such things for many years especially in server market like implementing router software, etc. So, to people who decide overall direction, there are at least something on which they can base their ideas.
So.. well.. I don’t know. There can be some sensitive and delicate issues for each players in WebKit partner companies, but I don’t think it’s typically more difficult to agree on it among them.
So.. I feel.. something business tactic from this technical decision…