El lun, 21-11-2011 a las 14:28 -0200, Gustavo Noronha Silva escribió: > On Tue, 2011-11-15 at 12:26 +0100, Carlos Garcia Campos wrote: > > El mar, 15-11-2011 a las 11:46 +0100, Sergio Villar Senin escribió: > > > 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. > > > > Also SoupMessageFlaggs and soupMessageHeaders? in that case we would > > need to go with the second approach and wrap everything else too. > > +1 to this approach; it is the most flexible and the least confusing. > The idea of handing the actual Soup objects to the browser seemed great > to me when I started down that path, but it turned out to be really > difficult to make it work.
I'm also wondering whether we should rename it to something like WebKitURIRequest/WebKitURIResponse (following the C API) or WebKitResourceRequest/WebKitResourceResponse (following WebCore), to avoid using the work Network which is confusing, because the URI of a request/response might be a local file. -- 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
