On Wed, Dec 13, 2000 at 12:18:39AM -0500, Greg Hudson wrote:
> > Hell, I'd guess that we mostly do the stream stuff for reading, and
> > that we don't seek, so I'd bet the write/seek arguments could be
> > shoved over to svn_stream_create_extended() or somesuch, and leave
> > the create function as a very bare-simple thing.
>
> We use streams for writing about as often as for reading.
Ah. Okee. I did say that I was guessing :-)
> Also, just to complicate matters, some streams (particularly write
> streams) want to know when the writing is complete. So far we've been
> indicating that with a zero-length write, but a separate "close"
> operation would be cleaner.
We can have svn_stream_close() which (under the covers) does a write with a
NULL buffer (not zero length!) as the close signal.
[ zero-len write as a close is problematic; it is easy for code to
"accidentally" write zero bytes; we wouldn't want to prematurely close the
stream ]
If we find it cleaner to use a seperate function, then only the stream
providers would need to change; all the users would already be set up to use
svn_stream_close().
I'd say that we're looking at something like this:
STREAM PUBLISHER FUNCTIONS
svn_stream_t * svn_stream_create_ro(pool, baton, read_func)
svn_stream_t * svn_stream_create_wo(pool, baton, write_func)
void svn_stream_set_seek(stream, seek_func)
STREAM USER FUNCTIONS
svn_error_t * svn_stream_read(stream, char *buffer, apr_size_t *len)
svn_error_t * svn_stream_write(stream, const char *buffer, apr_size_t *len)
svn_error_t * svn_stream_seek(stream, apr_off_t abs_position)
void svn_stream_close(stream)
The old read_fn and write_fn had a "temp pool" passed as an argument. Do we
still need to support that mechanism? i.e. do we need that fine-grained
control? IMO, a stream should use the initial pool for any allocations, and
it should be built to use a fixed/bounded amount of memory (non-proportional
to the stream)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006