Re: Interface Versioning

[Michael Meeks <michael ximian com>]

On 11 Jul 2001, JP Rosevear wrote:
> Interface versioning was a poor choice of subject.  Put it this way -
> how can I installed two versions of a component, the 1.0 interface
> version and the 1.1 interface version?  I don't have a need for the
> orb to do the versioning resolution.

	Don't. There is no good workable solution here. Please ensure that
both ends agree on the same contract: interface. If neccessary make sure
that the gtkhtml people add their methods at the end of the interface -
this will give some level of compatibility.

> Not at all.  How can multiple versions of gtkhtml be installed now?
> Especially when the idl interface changes.  This is a problem right
> now for proper gtkhtml/evolution packaging.

	How can multiple incompatible versions of anything be installed ?
either way - the most pernicious thing about it is the fact that people do
activation by interface name - and the interface name no-longer specifies
an interface, but rather a mess. Of course, people also do capability
based activation, and since all 15 installed versions of gtkhtml, with
different interfaces, all subtly differently broken have roughly the same
capabilities you will activate one ~ at random.

	Of course, you could create a new OAFIID for each gtkhtml
component, and activate the one that you specificaly wanted, and that you
magicaly new supported the precicely broken interface you expect.

	But this is just as much of a non-solution as interface
versioning.

	The correct approach is probably to use standard frozen interfaces
wherever you can, to add methods at the end of IDL interfaces, to be
careful about altering released interfaces.

	Ultimately your packages simply need to know that they have
certain contractural requirements - that these have been broken - and thus
that an atomic upgrade of several packages is required.

	I hope that helps,

		Michael./

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