Re: Are CORBA interfaces immutable?????

["Michael Rumpf" <michael rumpfonline de>]

If they are released they should be immutable !!!

The standard CORBA mechanism is of limited use in this scenario:

interface IFace {
#pragma version "1.1"
};

This will create a new TypeID for the interface and the CORBA narrow()
will not work anymore("IDL:IFace:1.1"). It will screw up all applications
that rely on
the old interface (IDL:IFace:1.0).

The following should be the best solution (As far as I don't miss anything
;-) :

interface IFace {
  // old methods
};

interface IFace2 : IFace{
  // new methods
};

The best way is probably to derive a new interface from the old one so that
narrowing to the old interface still works for old applications and new
applications can narrow to the new interface ( I think the same mechanism is
used for some of the "CORBA services" )

I can't remember the requirement for COM's Interface IDs, but I remeber that
it was a mess to clean up the registry from all the zombie entries. Each
time you changed the interface the MIDL compiler generated new GUIDs for
your interface. And forgetting to call your app with the /unregserver
parameter means bloating up your registry each time you change the M$ IDL
file.

A good book about this topic is "Essential COM" from Don Box. The first
chapter explains
versioning in great detail, and what the benefit of COM is compared to plain
old DLLs.

Michael


----- Original Message -----
From: "Diego Sevilla Ruiz (dsevilla@um.es)" <dsevilla@ditec.um.es>
To: "Ron Jones" <ronjones@xnet.com>
Cc: "Maciej Stachowiak" <mjs@eazel.com>; <gnome-devel-list@gnome.org>
Sent: Donnerstag, 31. August 2000 12:24
Subject: Re: Are CORBA interfaces immutable?????


>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Ron and all:
>
> Ron Jones wrote:
>
> > On Tue, Aug 29, 2000 at 10:31:43PM -0700, Maciej Stachowiak wrote:
> > >
> > > Nontheless, I think we really need to figure out some kind of solution
> > > for interface versioning. I think it's pretty clear a lot of
> > > interfaces being written now will have to change in the future.
> > >
> > >  - Maciej
> >
> > I think that the COM way is actually pretty reasonable. Interfaces do
not
> > change, period (implementations do, of coarse). If you need to change
your
> > interface, then you rename it, perhaps deriving from the previous
interface
> > if you are just adding methods, e.g.
> >
> > interface IClassFactory2 : IClassFactory
> >
>
> Why renaming and not using the IDL versioning? This is the COM way. But
IDL
> defines a version number using #pragma directives within the IDL file,
isn't
> it?
>
> #pragma version 1.1
>
> and so on. IR identifiers are something like
>
> IDL:Package/SubPagkage/Interface:version
>
> Why don't use them? We are using CORBA, not COM.
>
> >
> > Even if you have a guid based scheme to identify interface versions, you
> > would have a namespace pollution problem. It would be difficult for one
> > program to support different versions of the same interface if the
module
> > and interface names are identical. I think that once an interface is
> > released in a "stable" package, it should be immutable.
> >
>
> I agree.
>
> >
> > Ron
> >
>
> Regards.
>     diego.
>
> --
> Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dsevilla@um.es
>        Departamento de Ingeniería y Tecnología de Computadores
>            Facultad de Informática. Universidad de Murcia
> Campus de Espinardo  -  30080 Murcia (SPAIN).  -  Tel. +34-968-367570
> PGP:  http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
> \huge d\em\kern-.36em\lower-.2ex\hbox{\small sevilla}\kern-.1em@um.es
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> MessageID: ui2Hy0rIhwU8wQZrkaipc4c/rlNWKduh
>
> iQA/AwUBOa4ydNoq0AfJuWS3EQLWSACfbj42nV0bJOmi4j7CF9iQnPxBaGIAoNqo
> eIkEHlB68YegFSOdJkbO8Avz
> =pHPV
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list