On Tue, May 13, 2003 at 12:20:14AM +0200, Philipp von Weitershausen wrote:
> Greg Stein wrote:
> >> - headers-to-modules ratio -- we'd like to see each header
> >> handled by its own module, right?
> >
> >Nope. There is a definite cost to having a billion little extension
> >modules.
> >That is why a number of them are pulled into the util.i module.
>
> What cost? Performance? Memory?
Both, but mostly performance. Dynamically loading and linking a bunch of
little .so libraries is quite expensive. Part of the reason for slow startup
times on the big GNOME and KDE apps is because of the number of shared libs
that get loaded. I even notice it on 'svn' itself, and have started to worry
about the number of shared libs it relies on.
> >If I had my druthers, there would be just a single extension module. As it
> >is, I divided them along some probable use-case lines. (and also along the
> >dividing line of "will the FS library be around, or will the module only be
> >used client-side?")
>
> Okay, but then then please don't call it "util". util sounds much like
> optional, but it contains authentication stuff and pools, so it's
> actually quite important to any application. I suggest moving core
> things from util into a "core" extension module, if we can't have one
> module per one header (which I still prefer, actually).
Ah. 'core' would be fine -- no problems there. We can also have a small
util.py for backwards compat. ('from core import *')
>...
> >Let's avoid too many Python modules, please. One of the things that I
> >really
> >detest about Java is the one-class-one-file approach.
>
> Yes, agreed. I was actually only picking up cmpilato's file name
> suggestions. My idea of the bindings is this:
>
> libsvn/ # contains the extension modules and those only
> libsvn/_client.so
> libsvn/_wc.so
> libsvn/client.py
> libsvn/wc.py
> ...
>
> subversion/ # contains additional python classes and functions
> subversion/client.py
> subversion/wc.py
> ...
Rename that to 'svn/' and I like this arrangement.
> Developers can then go straight ahead and import from libsvn and
> optionally use stuff from the subversion package. Documentation for the
> libsvn package can be obtained right from the C headers (or whatever
> doxygen generates).
Yup. Sounds good.
I might also say that the libsvn/ modules do not remove the function
prefixes, while the svn/ modules import all the functions *with* their
prefixes removed. IOW, libsvn is simple wrappers to expose the
functionality, and the svn modules are the higher-level bits and ease-of-use
items.
> They also know what to expect in libsvn. I found out about FileDiff and
> all these other things only after I browsed the source code. There was
> not only no documentation for these things, I also did not expect any
> extra python code in the bindings. It seemed quite like a hack.
Of course it is a hack. No need to be patronizing about it, though. It isn't
like the bindings are more important than finishing SVN itself. Thus, the
bindings have always been second priority.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 00:38:32 2003