In general, I think splitting is a good idea. Philosophically, I'm
inclined to think that separate applications should be, well, separate;
and if they can't be separate (i.e., two-way dependencies), we shouldn't
try to make them appear so. The current relationship between AmberTools
and Amber is, well, idiosyncratic.
At risk of asking a dumb question, in a properly split release (so that
Amber is dependent on AmberTools) why would there be code duplication?
It seems to me straightforward enough to have (for example)
$AMBERTOOLS_HOME with its own bin, lib, etc.; and then to put something
in the Amber config that looks for an AMBERTOOLS_HOME/lib and
automatically adds that as a "-L" in config.h. I'm sure there are other
ways duplication could be avoided.
The big risk of a clean separation, for me, is backwards compatibility.
If we're to split the two, it follows that users need to be able to
update Tools without having to update Amber, and vice versa. For
example, let's say Amber 11 is released with AmberTools 1.4, and then
later AmberTools 2.0 comes out, and then Amber 12 comes out, and so on.
This would entail:
* Amber 11 compatible with AmberTools 1.4 and AmberTools 2.0
* AmberTools 2.0 compatible with Amber 11 and Amber 12
* Amber 12 compatible with AmberTools 2.0 and AmberTools 3
and so on. This is rendered more complicated by the non-gratis nature of
Amber; users may expect to be able to upgrade their AmberTools without
paying $$$ to upgrade Amber. Would we need to design each AmberTools so
that all past releases of Amber, plus any future releases of Amber
before the next release AmberTools, can talk to it? I think we shouldn't
have to do this; but we would need to make clear what versions of Amber
are compatible with any given version of AmberTools, so that users know
whether they must upgrade, must not upgrade, or can safely choose
whether to do so or not.
It would also probably tend to make the code more conservative, since
big structural changes might destroy backwards compatibility; such
changes would require either synchronous AT/Amber releases or major
patch work. And much more testing would also be required: for example, a
change in Tools would have to be tested against at least two versions of
Amber, being the development version and the most recent stable release.
But from a user's point of view, I think having a clean separation would
be much easier and clearer to work with. And I certainly don't like the
thought of two different versions of AmberTools on the same machine. Not
for reasons of space: as Jason so accurately points out, that's unlikely
to be a problem. But it leaves users open to the risk of two different
versions of the same executables and/or libraries, which seems like a
recipe for problems if, for example, a bug is fixed in one and not the
other. And I recall that we'd be the ones such users would turn to for
help, and we probably won't win many friends if, for example, we insist
that they muck around with their $PATHs and $LD_LIBRARY_PATHs whenever
they want to use sleap or ptraj.
Regarding branding and perception, I don't think that we run the risk of
a major problem there. If Amber is dependent on AmberTools, and the
official releases of both are in the same place, it would be hard for a
user to come away thinking, "They're completely different projects."
However - and this is just food for thought - the name AmberTools
suggested to me, until I learned better, that "Amber" is the key part
and "AmberTools" is just some optional extras. I long ago realised that
the opposite is true, but is it worth thinking about an alternative
naming scheme that better reflects reality, while keeping the
relationship between the two obvious?
On Sat, 2010-01-30 at 11:50 -0500, Jason Swails wrote:
> I'd call for Option 3 myself to try and optimize the pros and cons of
> Option 1. This idea was proposed by Ross, though I'm adding some
> details. Overall, I think it offers a good compromise between the two
> options.
>
> <<snip>>
>
> On Sat, Jan 30, 2010 at 9:22 AM, case <case.biomaps.rutgers.edu> wrote:
> > At the developers' meeting, there were various suggestions for how to
> > handle the Amber/AmberTools split. This is a request for comments for some
> > ideas along this line.
> >
> > <<snip>>
> >
> > Please think hard about the branding and perception issues -- the other things
> > are mostly technical that we can probably solve.
> >
> > ....thx....dac
> >
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 10:00:02 PST
