I'm currently working on downloads API for WebKit2 and I need to expose NetworkResponse which is not wrapped in WebKit2 API yet. In WebKit1 we have WebKitNetworkRequest and WebKitNetworkResponse, which are mostly the same because a SoupMessage represents both a request and response. So, both NetworkRequest and NetworkResponse are just a URI and a SoupMessage. Thinking about how to expose them in WebKit2 API several ideas came to my mind:
- Since both are the same because they contain a SoupMessage and a URI, maybe we can just expose SoupMessage directly. The problem I see with this approach is that most of the uses of NetworkResponse and NetworkRequest are just getting the uri. SoupMessage returns a SoupURI which is not so convenient to use, because you need to call soup_uri_to_string() which returns a new allocated string. - We can keep both objects, but wrapping the SoupMessage instead of exposing it, having different implementation depending on whether it's a request or response. For example webkit_network_response_get_headers() would return the SoupMessage response_headers. - Another option would be merging both objects into a single one, WebKitNetworkMessage?, since the implementation is mostly the same. We might add api to know whether it's a request or response (you should probably always know it from the context, though) webkit_network_mesasage_get_type(). - We could move the code to a base abstract class WebKitNetworkMessage, for example, and keep WebKitNetworkRequest and WebKitNetworkResponse as derived classes. They will be almost empty just providing _new() methods, similar to GtkBox, GtkVBox and GtkHBox classes in GTK+2. - And of course we can do the same we are doing in WebKit1 and expose both objects having the same implementation just with a different name. What do you think? any other idea? Second approach is the one I like the most FWIW. -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
