[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

New library init requirement to support *new* functionality?

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-06-19 20:55:41 CEST

From a conversation between Vlad and Garrett concerning requirements
for SASL libraries and a single-threaded initialisation:

>> Also, how do we make sure that sasl_{client,server}_init() is only
>> called once? I dug up this thread from the archives:
>> http://svn.haxx.se/dev/archive-2003-05/2224.shtml
>> Is there a solution for this?

>Well, it really depends on how correct we want to be. We can't be
>100% correct, since we can't rely on users of the Subversion libraries
>calling an initialize function, since we didn't have one in Subversion
>1.0, and thus we can't introduce that requirement now. We can add a
>new initialization function and request that people call it, but we
>still need to work even if it wasn't called. Perhaps making the
>current sasl init function you've got public, but inserting extra
>calls to it in ra_svn before we make use of sasl code, just in case...

>For other examples of this sort of thing, see svn_utf_initialize,
>although that's not really the same thing, since without it we still
>work, we just work more slowly. Also svn_fs_initialize().

Well, Garrett, I don't agree here: Since SASL is adding functionality
to our libraries, we'll be able to add new requirements: there's
nothing to be backward compatible with.

So, in this case, I'm arguing: We can require single-threaded init,
since, if the library-user doesn't call this function, we simply fall
back to our old behaviour. Nothing wrong with that: servers will need
to support it anyways (to support old clients) and clients will need
to support it (to support old servers).



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 19 20:56:18 2006

This is an archived mail posted to the Subversion Dev mailing list.