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
nsIProgressEventSink

New Necko Interface:
nsIStreamContentInfo

Necko Public Functions:
nsNetUtils

URILoader 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).

Reply via email to