Confirmed users
195
edits
User:Brahmana/Netwerk Docs/Connection Transaction Organization: Difference between revisions
User:Brahmana/Netwerk Docs/Connection Transaction Organization (view source)
Revision as of 07:25, 7 August 2008
, 7 August 2008no edit summary
(added abstract notes part) |
No edit summary |
||
| Line 49: | Line 49: | ||
* Apart from this delegation work, channel does the job of setting up the transaction if getting the data from the server. If not, then it takes care of the cache read. (So channel is not really dumb). | * Apart from this delegation work, channel does the job of setting up the transaction if getting the data from the server. If not, then it takes care of the cache read. (So channel is not really dumb). | ||
* Necko consumers will probably just see the channel. They will ask the nsIIOService to create a channel for the URI that they have. Based on the scheme of the URI, an appropriate channel is created. From the channel all protocol specific works starts. And the consumers just keep getting data and other notifications from the channel. | * Necko consumers will probably just see the channel. They will ask the nsIIOService to create a channel for the URI that they have. Based on the scheme of the URI, an appropriate channel is created. From the channel all protocol specific works starts. And the consumers just keep getting data and other notifications from the channel. | ||
* There is a global nsHttpHandler object, named gHttpHandler (obviously), which sort of acts as the manager of all connections. It creates the HttpChannel. There is probably something similar for other protocols also, I have not explored that part. From what I know this does something more also, which I do not know yet. <<Necko people -- something straight from your mind?>> | * There is a global nsHttpHandler object, named gHttpHandler (obviously), which sort of acts as the manager of all connections. It creates the HttpChannel. There is probably something similar for other protocols also, I have not explored that part. From what I know this does something more also, which I do not know yet. <<Necko people -- something straight from your mind?>> [The HTTP protocol handler also stores some global state, some preference values, the value of the User-Agent header; it caches some services; and it has a few helper methods. But mainly it's just an implementation of nsIProtocolHandler for HTTP. There is indeed one protocol handler for each supported protocol. Their job is basically to manage nsIURI and nsIChannel creation. --[[User:Biesi|Biesi]] 07:25, 7 August 2008 (UTC)] | ||
* Along with a nsHttpHandler, there is a nsHttpConnectionMgr. This is probably the one which manages the idle connections, active connections and probably allot connections when requested. <<Not sure of this part -- needs validation>> | * Along with a nsHttpHandler, there is a nsHttpConnectionMgr. This is probably the one which manages the idle connections, active connections and probably allot connections when requested. <<Not sure of this part -- needs validation>> [Sounds right to me. --[[User:Biesi|Biesi]] 07:25, 7 August 2008 (UTC)] | ||
** This one activates every nsHttpConnection, which eventually leads to a call in socket transport service, either resulting in the creation of a socket. | ** This one activates every nsHttpConnection, which eventually leads to a call in socket transport service, either resulting in the creation of a socket. | ||