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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to