Darin Fisher wrote:
> Since the protocol is implementing the nsIOutputStream, it
> knows how much you wrote. Moreover, if you write 0 bytes
> then it will know that you are finished. In other words,
> just like libc read, if there are no more bytes available
> then we can assume that end-of-file has been reached.
>
Hmm. I thought that you wanted to get rid of the need to have all of the data
ready and buffered? Suppose that my writer function does not have any data
available to write, but is expecting some shortly. What are the choices that he
can do? He can block which will block the channel or he can return zero which
will terminate the write since this will mean EOF. Is the writer expected to
block in this case? Maybe it depends on what I quantify shortly to me? What I
am thinking about here is maybe LDAP is doing a look up and wants to write its
data using AsyncWrite. There may be periods where OnDataWritable will be called
and this LDAP writer will not have any data to give it. Furthermore, there is no
really way to know when there will be data (imagine a search through AOL's/TW
employee database which is > 100000 records for some arcane piece of
information). It would be nice if the writer could say "hey, I am still working
here but have no data for you. Call me in a bit".
> At first glance, this may seem like a synchronization headache.
> Afterall, what would happen if the transport were to consume
> data faster than it could be supplied? Well, the short
> answer is that we have this problem with the existing
> AsyncWrite interface as well. With the current interface,
> the client supplies a nsIInputStream which the channel reads
> from. If there are no bytes available when the channel calls
> read, what should happen? The channel shouldn't busy wait and
> we can't block the channel's thread, so we have to handle it
> as an end-of-file.
>
I though the intent of this proposal was to rid us of this problem. My fault.
You said:
> This effectively requires the data to be buffered before it can be written to
the channel.
I took this to mean that there would be a way so that a writer can return zero
and that would not mean eof. Maybe this status would be return via some NS_ERROR
instead of the byte count. I guess what you are saying is that we can remove one
layer of buffering (the buffer between your "temp file" and the nsIOutputStream)
