> 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)
Note the asymmetry of the subject's (inter)face, suggesting an
affinity for petty larceny and gambling.
:)
> 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)
Yep. And if absolutely necessary, the stream could retain a reference
to its initial pool, and create a subpool for each read/write call.
So omitting the temp pool argument doesn't cripple anybody.
Received on Sat Oct 21 14:36:17 2006