There are instances in which the embedding app may want to supply it's own data (BYOD). There may or may not be a URI involved. Imagine an embedding app that simply has a buffer of html data it wants to load. They should just have to wrap that buffer in an nsIInputStream and hand it off ot the uri loader (note: we need to expose this api to the high level embedding api as well). Actually, maybe we should supply a Load(char *buffer) method as well so they don't even need an inputstream???
How about letting the client register with a special protocol handler that calls back to a client supplied object with a simple interface whenever content is requested? The client wouldn't need to write the protocol handler, just the callback. The callback would contain a single, simple method - "give me back a chunk of memory representing this URI". The protocol handler then takes the memory stuffs it in a stream and sends it off before deleting it.
I've seen a current implementation do this. Part of the problem is that initiation of the special handler isn't always clear (you basically have to generate a "foo:" url to kick things off). Usually the client knows when it wants to initiate the rendering, and it supplies its own buffer. Exposing a more raw Load() method has the same affect, yet all the client has to do is supply the buffer, and we don't have to involve a protocol handler. I think we sould try to avoid "special case" scenarios as they cloud architecture lines.
nom nsbeta2. fix attatched. mscott and rpotts have both reviewed it. This change extends the nsIDocShell api such that it can load data from a stream rather than an api. embedding clients need this so they can bypass our networking level to render data.
valeski, feel free to mark [nsbeta2+] when you are comfortable to go ahead on this.
fixed. this method now hangs off of the docshell.
Adding verifyme keyword.
Per valeski, ok to mark this Verified. Fixed is good! Goal!
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.