Re: Interface Versioning

[Michael Meeks <michael ximian com>]

Hi Larry,

On 11 Jul 2001, Larry Ewing wrote:
> For something like gtkhtml we have the very real, very serious problem
> of trying to develop a library and associated components using a
> component system that doesn't support any sort of versioning.  So we
> end up with massive packaging and distribution problems.

	Hmm. For the C API - this shouldn't be a problem - library
versioning helps you a lot. For interface versioning it is harder.

> We are not talking about versioning it at the ORB level we are talking
> about the practical issues involved in making software.  In real life
> situations interfaces change, and we'd like to come up with some semi
> standard method of dealing with it when it does happen.  So the issue
> becomes what things must a package change when it wants to implement
> an incompatible interface?

	Well - there are two ways of doing it:

	a) Have 2 interfaces with the same name, but radicaly different
signatures: this is totaly broken.

	b) Have 2 interfaces with different names and similar
signatures: this is correct.

	But I don't quite understand the question - why do you 'want to
implement an incompatible interface' - incompatible with what ?

> What if we want it to still be installed at the same time as a
> previous package/component?  Do we name the new interface something
> completely different or do we append a version number to the interface
> name?

	You need to change the interface name, you need to change the
OAFIID, you need to change the executable name / path, you need to change
everything - you have a new component.

> Adding an interface with a *2 name is the same as adding an interface
> with a *-x.x interface name, and I think that is what JP was
> advocating.

	Not so, this:

		GtkHtml_Name1 (o, &ev);   vs.
		GtkHtml_Name2 (o, &ev);

	is patantly different to:

		GtkHtml_Name (o, &ev);   vs.
		GtkHtml_Name (o, &ev);

	which IDL interface versioning will give you - creating a
confusing mess, and making unclear which version of which interface you
are actualy using.

> That of course doesn't solve the whole problem. To get this to coexist
> properly with a previously installed and incompatible
> interface/component combination that we want to keep we also have to
> change the executable name, the idl name etc.

	Yes of course. But this hardly solves the real issue. In the world
of shared libraries it is very easy to do library versioning. This is
because people 'activate' their libraries by saying

	'give me libgtkhtml.so.173'

	The way oaf activation happens is often more like:

	'give me something implementing the 'open' interface'

	If you go and change the signature of the 'open' method to take a
'froznik *' pointer instead of int length, and install two versions
implementing this interface - then the system acts erraticaly, ambiguously
and it is not possible to fix: the contract has been broken between
components.

	So. If you want to version things, then please do: I would
personaly install the binary / library for the component into a versioned
location [ this is easy ], setup an absolute path to it in the oafinfo
file - see bonobo/monikers for an example of the .oaf.in.in mechanism
needed for this.

	But then you hit the wall of trying to tell oaf which gtkhtml is
best - for ambiguity reasons, and you need to activate a precice version
of gtkhtml in each application that wants it.

	Ultimately you have a set of dependencies that you are partialy
but not fully shielded from by the component system - and that are not
explicit like library versioning, and the issue is not easy to solve.

	Foo,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot