Most of the restraints and other useful functionality are moving out of
the kernel. Currently the idea is that they go into a module called dsr
(for lack of another name) which would be modifiable by everyone. Only
the angle restraints and a couple of other non-kernel objects would be
left in the kernel. I propose instead we call it "basic" and move all
existing restraints into it. That way we have less random split of code
between modules. After all, does anyone want to remember that
"DistanceRestraint" is in IMP but "DistancePairScore" or
"NonbondedListScoreState" is part of IMP.dsr?
Let's not confuse the issues here. There are two quite separate issues:
1. Easier access to SVN for people wanting to try new methods.
2. Decision on what should and should not lie in the kernel.
I proposed creating the 'unstable' module to deal with (1). As for (2),
the kernel interfaces are comparatively stable, so in the short term at
least I don't envisage large changes there. (There is, of course,
nothing to stop you simply copying a kernel function into unstable and
developing it there. Once it's stable, the kernel version can be
updated, or it can be moved into a stable module.)
Before we get too carried away with modules, let's define some ground rules:
1. Modules group classes and functions by similar functionality, not by
author, and should be named accordingly. For example, the 'em' module
contains only classes for cryo EM fitting.
2. Each module has a responsible owner or group.
3. Modules should still obey IMP coding standards, code review is still
encouraged if possible, and major API changes should be advertised on
the IMP-dev mailing list.
4. Modules can link with external libraries that the IMP kernel does not
link with. However, these libraries must be publicly accessible (so
that others can use the module) and not be incompatible with the IMP
license (for example, no GPL libraries, but BSD or LGPL is OK).
5. For developmental code that doesn't obviously fit into a neat
category, the 'unstable' module is writable by all.
As for the kernel, clearly there is a need for guidelines for what lives
in there. For now, however, we could start by moving the experimental
stuff that is not relied upon by other projects into the 'unstable'
module. (Seems that this would be some or all of CoverBondsScoreState,
ParticleRefiner and subclasses, BrownianDynamics, RefineOncePairScore,
TunnelSingletonScore, WormLikeChain.)
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle