зеркало из https://github.com/mozilla/gecko-dev.git
81 строка
3.3 KiB
Plaintext
81 строка
3.3 KiB
Plaintext
/**
|
|
* Goals:
|
|
*
|
|
* (1) Model streams after NSPR I/O, thus making implementation easy and transparent
|
|
* (2) Allow both - blocking and non-blocking operations within the same API framework
|
|
* and in doing so streamlining the way application is developed
|
|
* (3) All stream implenetations become uniformed in both - blocking and non0blocking
|
|
* modes, thus taking partially the functionality of nsIOChannel's and allow simple
|
|
* transparent chaining of streams without encouraging excessive buffering
|
|
*
|
|
* This model will not support NT-style overlapped I/O; there's no good expression for it
|
|
* within NSPR either - do we need it?
|
|
*
|
|
* Changes:
|
|
* gagan: streams will not inherit from nsI*Stream to not confuse them with existing
|
|
* streams as behavior is a bit different
|
|
* ruslan: streams will not have a common base class and Close () operation - this will
|
|
* have to be done in the destructor
|
|
* ruslan: output stream will not have Flush () operation - this will need to be moved
|
|
* into some new BufferedWriter interface
|
|
*/
|
|
|
|
#include "nsISupports.idl"
|
|
#include "nsISimpleFailure.idl"
|
|
#include "nsICompletionEventListener.idl"
|
|
|
|
/**
|
|
* Quesion? Should we inherit from nsIInputStream and nsIOutputStream or these should be complete
|
|
* replacements since the semantic of Read/Write/Etc. is a bit different?
|
|
*/
|
|
[scriptable, uuid(aedae738-3041-4418-b808-40db58a9e7b9)]
|
|
interface nsIInputStream2 : nsISupports
|
|
{
|
|
/**
|
|
* Read data from the stream.
|
|
* @param aBuf the buffer into which the data is read
|
|
* @param aCount the maximum number of bytes to read
|
|
* @return aReadCount out parameter to hold the number of
|
|
* bytes read, eof if 0. if an error occurs, the
|
|
* read count will be undefined
|
|
* @comment in case of non-blocking call Read may return WOULD_BLOCK
|
|
* error code and the appropriate listener will be called upon
|
|
* completion. The consumer then still will have to call Read
|
|
* again to retreive the actual data
|
|
*/
|
|
|
|
[noscript] unsigned long Read (in charPtr buf, in unsigned long count);
|
|
|
|
/**
|
|
* Optional attribute which defines expected data length of the input
|
|
* stream. It's purpose in life is to aid i/o layers whith the length
|
|
* of the stream externally prescribed
|
|
*/
|
|
attribute long Length;
|
|
|
|
/**
|
|
* a number of bytes read from the stream
|
|
*/
|
|
readonly attribute unsigned long Count;
|
|
|
|
/**
|
|
* This attribute determines whether Read would block or not. In case of
|
|
* a non-blocking stream - completion listener will be called only when
|
|
* Read returns WOULD_BLOCK. Stream implementations are expected to be
|
|
* able to switch between blocking and non-blocking modes on the fly
|
|
*/
|
|
attribute boolean Blocking;
|
|
|
|
/**
|
|
* Optional completion listener: the listener will only be used when Read
|
|
* returns WOULD_BLOCK. There is no guarantee that the number of Reads will
|
|
* match the number of times the listener is invoked.
|
|
* In all cases the subsequent Read call must be made to retrieve the actuall
|
|
* data or an error code. The listener will always be called via Proxy object
|
|
*/
|
|
attribute nsICompletionEventListener Listener;
|
|
|
|
readonly attribute nsISimpleFailure StreamError;
|
|
};
|
|
|