On 11/15/2011 05:46 AM, Sergio Villar Senin wrote: > En 15/11/11 11:08, Carlos Garcia Campos escribiu: >> 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: > > In general I'd avoid exposing the SoupMessage basically because ideally > we will not need it in the future as it would become just an > implementation detail of the new libsoup stream API.
I think SoupMessage will still be around... we need somewhere to store all the parsed information (headers, etc). (Although I guess we could just add methods to SoupRequestHTTP?) But anyway, SoupMessage only exists for HTTP anyway; you should expose the SoupRequest object instead so the API works for other types too. And if it's a SoupRequestHTTP then the caller can get the SoupMessage from that. (Maybe there could be a WebKitNetworkRequest/Response helper method to get the SoupMessage directly too I guess.) > 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 could add "const char *soup_request_get_uri_as_string()" if that would be useful. -- Dan _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk