I am RAJAGOPALAN GANGADHARAN doing Computer science Engineering in India and a GSOC 2019 participant with aim of porting Webkit2 to Haiku. First of all I would like to thank everybody for giving me this wonderful opportunity and I promise to not let the hopes down. I didn’t know much about BeOS until I saw Haiku. Well to be honest I fell in love with the GUI of haiku. The tabs and grouping is really what I wanted, and I was searching my entire life.I am really hoping to see Haiku organization badge in my GitHub profile.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/rajagopalan/2019-05-08_introducing_myself_gsoc_2019/
Welcome to the Haiku community!
Welcome, and good luck with your project !
On behalf of every webbrowsing Haiku user, I wish you much success with your work!
Woudln’t rewriting the IPC to use BeMessages be a maintenance burden whenever upstream makes any changes to that? Or is Haiku’s BSD socket implementation considered inadequate?
Welcome and WebKit2 would be wonderful!
Thank you everybody for your kind wishes
Our sockets are pretty good yet we chose to rewrite despite the burden is not to give up on the Be Ecosystem and nativity
It’s a bit more complex than that.
The UI process (the “shell” of the web browser) is a regular BApplication with BWindow and all the usual things. As a result, it cannot both wait on BMessages and sockets in the same thread. So even if we were to use sockets, we would need to run them in a separate thread.
And it’s not like we are doing some crazy hacks to WebKit to put BMessages in it. That’s how WebKit is meant to be used. They use a GLib event loop for the GTK port, but a completely different system for the Mac and Windows ports of it. And the Qt port uses a QApplication event loop. And we can very well provide an implementation of their IPC using BMessages (in fact a large part of the work is already done to encode/decode data to BMessages in the existing port, the only missing part is setting up the BMessengers between different process)
This is the reason we decided to use WebKit for the system browser: it really allows us to provide something that integrates with the native APIs (of course, because that’s also how Apple uses it), and does not run on top of a custom “platform abstraction” that we would have trouble using in a standard application.
What Blink does is fine when your goal is just to build a web browser. But it isn’t as much suitable when you want a generic framework for embedding web views into native applications (for example, HTML view in a mail client or an RSS reader).
Ok, yeah that makes complete sense.