[Cgl] Specification of a cut generator

[Lou Hafer]

Folks,

	I'd like to put in an opinion in favour of giving Cgl an interface
that's independent of OsiSolverInterface.  I'm sympathetic to John's comment
that it will require extensive changes to many of the existing cut generators.
But I think that there are significant disadvantages to holding to an OSI or
derivative class as the sole interface.  Suppose that one were to define an
OsiCglSI class, derived from the OSI base class.

	To my mind, the biggest problem is the sheer complexity of an OSI
object.  There are something like 170 distinct methods defined for the OSI base
class, and a fair chunk of these are simply not necessary in all but the most
elaborate of cut generators.  Using an OsiCglSI object as the standard parameter
makes it pretty well impossible to see what data and functionality is actually
needed within a cut generator.  On the flip side, by defining CglData/Param/
TreeInfo classes on a per-generator basis, the needs of the generator, in terms
of data (and its const'ness), and parameters, becomes much easier to see.

	With an OsiCglSI class, we'd still need to take some care to avoid the
issue of virtual calls.  The OSI base set/get methods are primarily virtual or
pure virtual.  Seems to me we'd need to specify OsiCglSI as the parameter type
(not OSI base) to avoid the overhead of virtual calls, which loses some
flexibility.  If we retain OSI base as the parameter type, there would be no
real advantage over CglData/Param and derived classes.

	An OsiCglSI object is a convenient container only if you have one handy.
If you're creating one for the sole purpose of calling a cut generator, it's
harder to justify.  Particularly in code that's otherwise independent of OSI
(Matt G.'s motivation).  Also in code that's going to be called from within an
OSI (might not be an important issue in this instance).  But from the user side,
no significant difference between OsiCglSI and CglData/Param, except the
overhead of bringing in the OSI base class.

	More abstractly, the direction we're trying to move OSI2 is to separate
the business of maintaining the model instance from the business of talking to
the solver.  In this architecture, a cut generator is just another object that
wants to manipulate the model.  Using an OsiCglSI as an intermediary makes less
sense.

	The single biggest advantage to sticking with an OsiCglSI type of
interface is that we avoid rewriting big chunks of the generators.  But we're
perptuating questionable software engineering to do it.  One way of minimising
the impact on the maintainers of individual cut generators would be to define
the new interface and then put the onus of conversion on the folks who see a
need for the new interface. Generators get converted whenever a motivated 
individual shows up and volunteers.

						Lou