Re: [webkit-dev] WebKitGtk network backend
On Monday 29 December 2008 08:14:02 Paul Pedriana wrote: > FWIW, I rewrote our version of the networking back-end support to use a > generic pure-virtual interface. That way all those #ifdefs in the code went > away and the back-end requirements became clearer and easier to provide. We > are using our own http/ftp/file support that is different from libsoup, > curl, etc. An interesting result of this is that multiple back-ends can be > simultaneously active; this allows one library to support ftp while another > supports http in the case that you (like us) don't have a single library > that does both. It also allows for a clean implementation of a disk cache, > as a disk cache is merely an http handler that gets first shot at > http-provided data. Another result is that custom URI schemes (e.g. > blah://) can be transparently supported by applications, which is useful > for custom platforms and uses such as ours. > > Somebody a few weeks ago was talking about pure-virtual interfaces in > WebKit, and while my response to him was one of caution in getting carried > away with such interfaces, IMO this is a case where they are beneficial. > Everything right, but we talk about API design and the fundamental question is if we wrap a generic interface and make it more generic or if we just expose a handle to the library z. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
FWIW, I rewrote our version of the networking back-end support to use a generic pure-virtual interface. That way all those #ifdefs in the code went away and the back-end requirements became clearer and easier to provide. We are using our own http/ftp/file support that is different from libsoup, curl, etc. An interesting result of this is that multiple back-ends can be simultaneously active; this allows one library to support ftp while another supports http in the case that you (like us) don't have a single library that does both. It also allows for a clean implementation of a disk cache, as a disk cache is merely an http handler that gets first shot at http-provided data. Another result is that custom URI schemes (e.g. blah://) can be transparently supported by applications, which is useful for custom platforms and uses such as ours. Somebody a few weeks ago was talking about pure-virtual interfaces in WebKit, and while my response to him was one of caution in getting carried away with such interfaces, IMO this is a case where they are beneficial. Paul On Tuesday 23 December 2008 16:28:59 Dan Winship wrote: Christian Dywan wrote: in fact Glib is a requirement, libSoup relies essentially on features of the GObject system. But that is already it. There are no Gnomish requirements on top of that, the libsoup-gnome library is optional and not needed for normal functionality. Actually, libsoup requires libxml2 too (for XML-RPC support), although it could be changed to use a native Windows XML API on Windows, if someone wrote a patch. But that's it, and the entire point of libsoup-gnome is that I don't want to add any more dependencies to libsoup itself. Let us not mix issues. We are not proposing to remove the curl implementation from WebCore (I'm aware that Windows, WX are using it) but we are at a cross road for the WebKit/Gtk+ API. >From what I know we have the need to export networking (and cookies) and have a couple of options 1.) Export a curl and soup handle in the API, and depending on whatever someone (e.g. a distro) used to configure the API exposing curl/soup will return a Null pointer... A user of the API would have to implement both soup and curl as he does not know which the final version will use... 2.) Design a network abstraction... alienate both soup and curl people 3.) pick curl 4.) pick soup >From what I know 1st and 2nd are no options. So it is either curl or soup and soup has a lot of what we need and aligns nicely with Glib/Gtk+ and the current consumers (epiphany/midori) already use the soup backend, gstreamer is using it as well. For me soup looks like the clear winner (even if I still need to install the dev packages). z. PS: libxml2 is used by WebCore as well ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
Hi, On Tue, Dec 23, 2008 at 10:26 AM, Gustavo Noronha Silva wrote: >> The "Redistributable" WebKit on Windows currently uses the cURL >> backend. I am fully in favor of switching to libSoup for this >> platform as well, if it is known to work properly on Windows. >> > I'm not sure the "redistributable" windows port needs to switch to > libsoup. Only the GTK+ port on Windows would switch, by the current > proposal, and curl can be specialized even more to work for the wx and > windows ports, since GTK+ would no longer use it. After talking with Kevin on IRC, we will continue with the cURL back-end for the wx and "Redistributable" ports of WebKit. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
On Mon, 2008-12-22 at 14:03 -0800, Brent Fulgham wrote: > The "Redistributable" WebKit on Windows currently uses the cURL > backend. I am fully in favor of switching to libSoup for this > platform as well, if it is known to work properly on Windows. > > I am a bit concerned that it seems to be heavily tied to the Gnome > platform. Will I end up having to pull in glib and other Gnome > dependencies if I wish to use it? I'm not sure the "redistributable" windows port needs to switch to libsoup. Only the GTK+ port on Windows would switch, by the current proposal, and curl can be specialized even more to work for the wx and windows ports, since GTK+ would no longer use it. See you, -- Gustavo Noronha Silva GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
On Tuesday 23 December 2008 16:28:59 Dan Winship wrote: > Christian Dywan wrote: > > in fact Glib is a requirement, libSoup relies essentially on features > > of the GObject system. But that is already it. There are no Gnomish > > requirements on top of that, the libsoup-gnome library is optional and > > not needed for normal functionality. > > Actually, libsoup requires libxml2 too (for XML-RPC support), although > it could be changed to use a native Windows XML API on Windows, if > someone wrote a patch. > > But that's it, and the entire point of libsoup-gnome is that I don't > want to add any more dependencies to libsoup itself. Let us not mix issues. We are not proposing to remove the curl implementation from WebCore (I'm aware that Windows, WX are using it) but we are at a cross road for the WebKit/Gtk+ API. >From what I know we have the need to export networking (and cookies) and have a couple of options 1.) Export a curl and soup handle in the API, and depending on whatever someone (e.g. a distro) used to configure the API exposing curl/soup will return a Null pointer... A user of the API would have to implement both soup and curl as he does not know which the final version will use... 2.) Design a network abstraction... alienate both soup and curl people 3.) pick curl 4.) pick soup >From what I know 1st and 2nd are no options. So it is either curl or soup and soup has a lot of what we need and aligns nicely with Glib/Gtk+ and the current consumers (epiphany/midori) already use the soup backend, gstreamer is using it as well. For me soup looks like the clear winner (even if I still need to install the dev packages). z. PS: libxml2 is used by WebCore as well ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
Hi Brent and all, On Dec 22, 2008, at 2:03 PM, Brent Fulgham wrote: Hi, On Mon, Dec 22, 2008 at 2:29 AM, Gustavo Noronha Silva wrote: On Sun, 2008-12-21 at 21:29 +0100, Christian Dywan wrote: So, I'd like to suggest to make libSoup the only backend. We would then require a recent (unstable) libSoup, similar to how Gtk+ depends on the latest (unstable) Glib. Xan Lopez has agreed already on IRC. The "Redistributable" WebKit on Windows currently uses the cURL backend. I am fully in favor of switching to libSoup for this platform as well, if it is known to work properly on Windows. I am a bit concerned that it seems to be heavily tied to the Gnome platform. Will I end up having to pull in glib and other Gnome dependencies if I wish to use it? The wx port uses cURL as well, and the glib main loop requirement leads me to think this might not be the best route, at least for wx. As long as the cURL code doesn't get removed from the tree, though, I'm happy. :) Thanks, Kevin Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
Christian Dywan wrote: > in fact Glib is a requirement, libSoup relies essentially on features > of the GObject system. But that is already it. There are no Gnomish > requirements on top of that, the libsoup-gnome library is optional and > not needed for normal functionality. Actually, libsoup requires libxml2 too (for XML-RPC support), although it could be changed to use a native Windows XML API on Windows, if someone wrote a patch. But that's it, and the entire point of libsoup-gnome is that I don't want to add any more dependencies to libsoup itself. There is one other possible complication though; WebKit's soup backend uses libsoup's asynchronous API, which requires there to be a glib main loop running. That's automatically true for a gtk-based program, but wouldn't be true for a Windows-API-based program, and I'm not totally sure if you can run the glib main loop and still have the Windows event loop function correctly. One possibility if not would be to run a glib loop in another thread, although that may cause problems with callbacks being invoked in the wrong thread and having locking/concurrency issues, etc... (It looks like the curl port deals with the mainloop problem by having the I/O be driven by timeouts rather than actually polling?) Anyway, this is going to require someone who knows more about both Win32 and WebKit than I do to figure out. -- Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
Am Mon, 22 Dec 2008 14:03:36 -0800 schrieb "Brent Fulgham" : > Hi, > > On Mon, Dec 22, 2008 at 2:29 AM, Gustavo Noronha Silva > wrote: > > On Sun, 2008-12-21 at 21:29 +0100, Christian Dywan wrote: > >> So, I'd like to suggest to make libSoup the only backend. We would > >> then require a recent (unstable) libSoup, similar to how Gtk+ > >> depends on the latest (unstable) Glib. Xan Lopez has agreed > >> already on IRC. > > The "Redistributable" WebKit on Windows currently uses the cURL > backend. I am fully in favor of switching to libSoup for this > platform as well, if it is known to work properly on Windows. > > I am a bit concerned that it seems to be heavily tied to the Gnome > platform. Will I end up having to pull in glib and other Gnome > dependencies if I wish to use it? Hey Brent, in fact Glib is a requirement, libSoup relies essentially on features of the GObject system. But that is already it. There are no Gnomish requirements on top of that, the libsoup-gnome library is optional and not needed for normal functionality. So it comes down to whether or not Glib is feasible for your port. ciao, Christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
Hi, On Mon, Dec 22, 2008 at 2:29 AM, Gustavo Noronha Silva wrote: > On Sun, 2008-12-21 at 21:29 +0100, Christian Dywan wrote: >> So, I'd like to suggest to make libSoup the only backend. We would then >> require a recent (unstable) libSoup, similar to how Gtk+ depends >> on the latest (unstable) Glib. Xan Lopez has agreed already on IRC. The "Redistributable" WebKit on Windows currently uses the cURL backend. I am fully in favor of switching to libSoup for this platform as well, if it is known to work properly on Windows. I am a bit concerned that it seems to be heavily tied to the Gnome platform. Will I end up having to pull in glib and other Gnome dependencies if I wish to use it? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
On Sun, 2008-12-21 at 21:29 +0100, Christian Dywan wrote: > So, I'd like to suggest to make libSoup the only backend. We would then > require a recent (unstable) libSoup, similar to how Gtk+ depends > on the latest (unstable) Glib. Xan Lopez has agreed already on IRC. As someone who has been building/testing/developing/using WebKit/GTK+ with libsoup from the start, I agree. > Of course, we actually have a use case, that is we agreed to introduce > libSoup specific API: > > https://bugs.webkit.org/show_bug.cgi?id=22624 I also agree with this API adition, as discussed in the Soup Cookies patch IRC meeting some time ago. See you, -- Gustavo Noronha Silva GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
Hello I am +1 for this. Do you have any IRC log so we can follow your reasoning with this matter? Best Regards -- Arthur Webkid 於 日，2008-12-21 於 21:29 +0100，Christian Dywan 提到： > Heya, > > the Gtk port of WebKit currently supports two network backends, that is > Curl and libSoup. The plan always was to improve libSoup to an extend > where it supersedes Curl, but libSoup is deemed not mature enough up to > this day. As far as I'm aware most of the Gtk contributors are > in favour of dropping Curl and supporting only libSoup. > > If libSoup is the only backend, we can easily make use of libSoup API > in applications, which means we don't have to dublicate interfaces in > WebKit. And distributions will build one WebKit build, instead of half > of them using a different backend. In the end libSoup will become as > stable as it has to be, if the time invested in maintaining Curl > support can instead go into improving the libSoup code. > > Note that with regard to packaging, libSoup is "a walk in the park" > compared to WebKit, it is built easily and quickly. And it is > portable, that is it doesn't depend on GNOME and it is usable for > instance on Win32. As far as stability is concerned, libSoup surely > isn't less stable than rendering or scripting in WebKit trunk. > > So, I'd like to suggest to make libSoup the only backend. We would then > require a recent (unstable) libSoup, similar to how Gtk+ depends > on the latest (unstable) Glib. Xan Lopez has agreed already on IRC. > > Of course, we actually have a use case, that is we agreed to introduce > libSoup specific API: > > https://bugs.webkit.org/show_bug.cgi?id=22624 > > If anyone has a good reason for not doing this, please speak up now or > remain silent forever ^_^ > > Yours, > Christian > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitGtk network backend
Heya, the Gtk port of WebKit currently supports two network backends, that is Curl and libSoup. The plan always was to improve libSoup to an extend where it supersedes Curl, but libSoup is deemed not mature enough up to this day. As far as I'm aware most of the Gtk contributors are in favour of dropping Curl and supporting only libSoup. If libSoup is the only backend, we can easily make use of libSoup API in applications, which means we don't have to dublicate interfaces in WebKit. And distributions will build one WebKit build, instead of half of them using a different backend. In the end libSoup will become as stable as it has to be, if the time invested in maintaining Curl support can instead go into improving the libSoup code. Note that with regard to packaging, libSoup is "a walk in the park" compared to WebKit, it is built easily and quickly. And it is portable, that is it doesn't depend on GNOME and it is usable for instance on Win32. As far as stability is concerned, libSoup surely isn't less stable than rendering or scripting in WebKit trunk. So, I'd like to suggest to make libSoup the only backend. We would then require a recent (unstable) libSoup, similar to how Gtk+ depends on the latest (unstable) Glib. Xan Lopez has agreed already on IRC. Of course, we actually have a use case, that is we agreed to introduce libSoup specific API: https://bugs.webkit.org/show_bug.cgi?id=22624 If anyone has a good reason for not doing this, please speak up now or remain silent forever ^_^ Yours, Christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
