Hello all,
I'd like to propose an addition to our nsIInputStream infrastructure. Please
let me know what you think.
Basics:
I propose adding this interface:
interface nsICloneableInputStream : nsIInputStream
{
nsIInputStream clone();
};
The clone() method returns a copy of the stream in the most efficient manner
possible. This might mean different operations depending on the concrete
implementation of the stream.
For example,
* nsFileInputStream would simply dup() its file descriptors like when
serializing across IPC.
* nsStringStream would simply do an nsCString-style copy construction.
* nsPipe would create a new nsPipeInputStream that reads from the same
underlying pipe buffer. The buffer is maintained until all cloned input
streams are closed.
Motivation:
In order to implement Fetch we need to be able to clone Request and Response
body streams. [1] These body streams can be provided a number of ways
resulting in different nsIInputStream implementations being used. (Essentially
the list above.)
Currently it seems the only infrastructure we have for performing a clone-type
operation is to use nsIInputStreamTee. Unfortunately this almost always does
the sub-optimal thing in terms of memory/CPU performance by copying the entire
stream into a new buffer. Also, it requires that one side of the stream be
fully read in order for the other side to have access to all the data. If you
have a slow reader on the primary stream then you may delay a fast reader on
the other side.
If instead we allow the underlying stream implementations decide how to produce
a copy then we can avoid these problems. This is important for Fetch and
ServiceWorkers in order to support potentially huge Response bodies in an
efficient way.
Thoughts? Is there an existing way to accomplish this without the problems of
nsIInputStreamTee?
Thank you!
Ben
[1] https://fetch.spec.whatwg.org/#dom-response-clone
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
