I guess, now I'm wondering why nsIStreamContentInfo is part of the request being returned, rather than being on the channel itself. I guess that I'm assuming that for a given channel, the content-type and content-length are fixed, regardless of how much of the data you actually read... How could these values ever change for a given channel?
I can see how the transferCount and transferOffset attributes of the channel should be moved into the request, but not the content-type and content-length attributes since they are supplied by the server for a given URL...
what am I missing?
-- rick
Doug Turner wrote:
Hey rick. First thanks for taking a look at these changes.I needed to change the URILoader interfaces because we (as implementers of DoContent) need to know the status, content type, content length, ect. of a particular request. Just passing the nsIChannel (the logical connection) is not enough information.
Rick Potts wrote:
hey doug,Do we really need to change the URILoader interfaces to use nsIRequests instead of nsIChannels?
It seems as if the URILoader will always want to deal with a channel... So, why not leave those alone to further document this fact?
-- rick
Doug Turner wrote:
Based on bug http://bugzilla.mozilla.org/show_bug.cgi?id=65272, I am needing to make some small changes to the public interfaces to Necko and to the URILoader.The changes basically are twofold. First, removing the buffer max size and buffer segment count from some of the functions. These attributes are really tuning parameters and should be left up to the internals of the implemention.
The second change, which has a bigger impact, is replacing the nsIChannel in parameter with an nsIRequest. Basic transfer state information will be in the nsIRequest interface whereas the nsIChannel will hold the logical connection information. This will allow for implementions to |fork| off multiple requests. An actual example will be the socket transport where it can hand back two requests, one for reading and one for write. The consumer can not cancel, suspend, resume, ect. each request seperately.
What this means for customers:
If you are needing to get to the nsIChannel from the nsIRequest, you will have to make a functional.
nsCOMPtr<nsIRequest> request; // somehow initialized.
nsCOMPtr<nsIChannel> requestsParentChannel;request->GetParent(getter_AddRefs(requestsParentChannel));
As you will also note, content information is not on the nsIRequest. If you believe that the request has content info (which it probably does if you are are listening to a read or something), you can QueryInterface for the new nsIStreamContentInfo:
nsCOMPtr<nsIRequest> request; // somehow initialized.
nsCOMPtr<nsIStreamContentInfo> contentInfo = do_QueryInterface(request);
if (contentInfo)
...What this means for nsIChannel Implementers:
Until your transaction request state is factored out of your nsIChannel implemention into a nsIRequest, you can return the nsIChannel's |this| (assuming that you derive from both) where you are required to return a nsIRequest. This is what has been done for basically all protocols and the file transport. You will also have to derive from the nsIStreamContentInfo so if you support content info and content length attributes. Lastly, if you can give back a nsIFile, you should implement nsIFileChannel. Please send me mail, if you run into any problems, or have q's.
Necko Interfaces:
nsIChannel
nsIDownloader
nsIIOService
nsILoadGroup
nsIRequest
nsIStreamListener
nsIStreamLoader
nsIStreamObserver
nsIProgressEventSinkNew Necko Interface:
nsIStreamContentInfoNecko Public Functions:
nsNetUtilsURILoader Interface:
nsIContentHandler
nsIDocumentLoaderObserver
nsIURIContentListener
nsIURILoader
I will be converting the Seamonkey build over to using these new interface. If you have some area of code that you want me to convert, please send me mail and include instructions on how to build (if it is not obvious).
