API cleanups for 2.0 (was Re: Issue 780 and status and notify functions)

On Mon, 2004-05-24 at 09:39, kfogel@collab.net wrote:
> No reason for that list to be private, yah. Should we file one issue
> for general API cleanups, or N issues, one per cleanup?

The main problem with using one issue for N tasks is that it's hard to
keep track of what's finished and what's not. We could make a keyword,
perhaps.

> Maybe start by posting your list, then we'll go from there...

Sure. Some of these could be "fixed" in 1.x by adding new APIs and
deprecating old ones, but it mostly doesn't seem worthwhile since we
wouldn't be getting any user-visible functionality out of it.

1. Callbacks should always have pool arguments. Otherwise we wind up
creating and destroying subpools in the callbacks, which is
anachronistic and less efficient than the usual iteration-pool
approach. Specific places I have noticed lack of callbacks include the
svn_stream callbacks and svn_txdelta_window_handler_t.

2. Right now, the svn_txdelta interface has this little side-feature
tacked on where it will, in addition to computing a delta, calculate the
MD5 sum of the target data passed in. This is totally out of scope for
the delta interface; we should take out that functionality and replace
it with a meta-stream which computes MD5 sums while reading or writing
data from an underlying stream.

3. svn_fs_unparse_id should return a C string.

4. The relationship between svn_fs_abort_txn and svn_fs_purge_txn feels
strange and implementation-dependent. Perhaps the easiest answer is to
ditch svn_fs_abort_txn() and make svn_fs_purge_txn() work on live
transactions.

5. Our timestamp parser should eliminate support for the deprecated
format.

6. Notification callbacks should have an error return, not a void
return.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 24 17:23:25 2004