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

[Greg Hudson <gh...@MIT.EDU>]

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

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

[kf...@collab.net]

Branko Čibej <br...@xbc.nu> writes:
> I'd prefer a 2.0 API meta-issue that lists all the specific API
> changes as dependencies. That lets you create nice dependency trees,
> jump back and forth between dependent/depending issues, etc.

Done.  The meta-issue is #1880, and 1881-1886 are the dependencies.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Branko Čibej <br...@xbc.nu>]

Greg Hudson wrote:

>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.
>  
>
I'd prefer a 2.0 API meta-issue that lists all the specific API changes 
as dependencies. That lets you create nice dependency trees, jump back 
and forth between dependent/depending issues, etc.




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

["C. Michael Pilato" <cm...@collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:

> 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.

Also, all callbacks should return svn_error_t's.

> 3. svn_fs_unparse_id should return a C string.

+1

> 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.

If we do this, then "abort" is probably the right unified function
name to use.

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

See previous comment re: callbacks.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org