Hi all,
Here is a breif overview of what I am planning to change in necko,
specifically nsIChannel and nsIRequest.
--
Doug Turner
[EMAIL PROTECTED]
Changes coming to nsIChannel
Currently with nsIChannel, it is to do overlapped reading and
writing. Currently there is no way to:
(a) suspend,
(b) resume,
(c) cancel,
(d) get status of,
(e) set transferCount
(f) set transferOffset
of seperate AsyncRead()/AsyncWrite calls
Here is the proposed fix:
Make AsyncRead and AsyncWrite return nsIRequest's.
- all callers of AsyncRead, and AsyncWrite will be modified to use
the return nsIRequest instead of the nsIChannel for nsIRequest
operations.
- nsIChannel implementions that are not ready to refactor state into
the nsIRequest will return themselves from AsyncRead/AsyncWrite.
Changes to nsIChannel and nsIRequest interfaces
- Add new AsyncRead and AsyncWrite calls which take:
(a) transfer offset and transfer length
(b) load attributes
(c) pipelining allowed.
- move attributes from nsIChannel to nsIChannelRequest (different name?).
(a) content type
(b) content length
(c) load group
- Make nsIChannel derive from an nsISupports, not a
nsIRequest. There may be two different nsIReqests return by a
nsIChannel (a nsIRequest from AsyncRead, and another from
AsyncWrite), it does not make sense for channels to be an nsIRequest.
- There will be *no* accessors to go from a nsIChannel to one of the nsIRequests
(why?).
- nsIRequest will have an attribute for the parent nsIChannel.
Modify LoadGroups
- LoadGroups should only hold on to nsIRequest, not nsIChannel's.
If the loadgroup needs the parent channel, it should use the new
attribute on nsIRequest.
- The loadgroup should also hold the default channel as a
nsIChannel. The first entry in its list will be that channel's
nsIRequest.
