Re: Delta-composer && (undefined but required) stream behaviour

Erik Huelsmann <ehuels@gmail.com> writes:
> While writing new streams which I want to use to feed the delta
> composer, I noticed the delta composer expects streams to support
> reads after partial results have been returned. Ofcourse, a read like
> that should return a zero-length block, but nowhere in the stream docs
> is this requirement documented.
>
> Is it a bug in the window composer, or in the stream documentation?

It sounds like at least a buglet in the window composer.

This documentation in svn_stream.h clearly says that a short read is
okay the first time:

 * The read and write handlers accept length arguments via pointer.
 * On entry to the handler, the pointed-to value should be the amount
 * of data which can be read or the amount of data to write. When the
 * handler returns, the value is reset to the amount of data actually
 * read or written. Handlers are obliged to complete a read or write
 * to the maximum extent possible; thus, a short read with no
 * associated error implies the end of the input stream, and a short
 * write should never occur without an associated error.

But yeah, we don't talk about what happens if you do another read on
the same stream :-)

> (I'm tempted to say it's a bug in the window composer, but that it's
> desirable to have streams support the behaviour even if we fix the
> window composer...)

If we can change ("fix") the window composer to not do this, then why
would we still think it's desirable for streams to support this
behavior? Is there another use case?

This is not a rhetorical question, by the way. If we can think of a
reason why it's useful, I'm all for explicitly documenting that
streams should allow reads after the first short read. But if there's
no use case, I instinctively feel that streams should be strict by
default.

Thoughts?,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org