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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
|
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
