On Wed, Dec 13, 2000 at 10:26:15AM -0500, Jim Blandy wrote:
>
> > 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.
>
> :)
Heh. Like I said: it adheres to the common case. A better way to phrase it
would be: "simple things are simple, complex things are doable."
No need to complicate the simple case. (i.e. shove the seek "out")
> > 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.
Good point!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006