id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
42	Keep interface consistency with preexisting software	marq	Huw Lewis	"This is more of a discussion starter (I hope).

So far, I have taken parts of the software (in particular the code for ncdf90 and udunits90)
from other libraries of mine, most notably tools90, math90 and ncdf90 (which will have their
own websites very soon (early November). The advantage is that more or less reasonably tested
code could simply be used; over time I complete(d) the documentation (and still do), and that
is beneficial for everyone. In addition, updates to the parent library can be included into
ROPP by simply including a new version. There will be a couple of more modules coming for the 
1DVar; much of what I have done over the last few days is cleaning up code in that libraries
for the future inclusion in the ROPP.

However, from (my) maintanance point of view, bugfixes should really go through the main
library instead of applying local patches in ROPP without feeding them back to the parent
library. Another issue is that interfaces should be kept consistent with the parent library,
as should the module files be. Because if ROPP is installed over an already existing ncdf90
(say), and the interface changes, programs will core dump without any reasons. If ROPP and 
tools90 libraries are used in the same program, a uncoordinated change in the interfaces on 
one side will result in braeking the code (yeah, I had that when I started to try to process
Axel's PD data...:-(() 

Yet another issue is that we sometimes only have subparts of the modules from the original
library. That is desireable from Dave's consolidation point of view (#40). I have started
experiment with a 'lite' version of modules (in ropp_tools/strings/strings-lite.f90) which evaluates to a strings.mod when compiled, but only has the interfaces for those routines
actually contained in the stripped down version of the full strings module. This means that
installing ROPP over an existing tools90 installation removes functionality, and that's not
so nice if you have other programs relying on that. The solution is to reinstall the tool90
library on top of the ropp_tools, as one then gets the tools90 version of the software, and
additional functionality from the ropp.

I've decided to give Dave his consolidation and use the above mentioned workaround for my
development environment. However, I still have to rely that you won't change the interfaces
to all preexisting functions and subroutines, as this would break a lot of my (and maybe
other people's) stuff.

On the other hand I see a danger that some divergence will sooner or later occur if 
there isn't a firm commitment to keep the interfaces consistent. So I would like to ask you
to think about how you want to handle this issue in the future:

 a) Commit to interface consistency with the preexisting libraries and use the website of
these libraries for bug reports / fixing. In that case, I would sit down and document
how to import updated versions into the ropp code base. I would also commit to the usual
open source ""support"" for these libraries (i.e., helping to fix things if time allows,
and give access to the development repository).

 b) Decide to avoid the dependency on my OS libraries. That's of course fine with me, but
in that case I would like to ask you to change the routine and module names for all 
components.

Let me know what you think."	task	closed	minor	4.0	ROPP (all)	0.7	fixed		dave.offiler@… carlo.buontempo@… axel.vonengeln@…