Re: finalize in ORBit-0.5-stable?

[Elliot Lee <sopwith redhat com>]

On Wed, 11 Apr 2001, Phil Dawes wrote:

> Ah - I see your point. However we are now faced with the following
> dilema:
>
> People using ORBit-stable (i.e. everyone) can't write transient
> servers which either:
>
> a) don't leak memory
>
> or
>
> b) will work with future versions of ORBit. (i.e. corba compliant ones
> which call _fini on etherealization)

> Which means that this problem is only going to get worse since people
> will continue to hack round this bug. I am wondering how we can
> transition these apps to use a 'working' version of ORBit in the
> future. How about the following:
>
> - provide a runtime switch for disabling the _fini() functionality
> - if the servant is etherialized without the switch, output a runtime warning
>
> Does this sound reasonable? Any better ideas?

Hmm, I don't think it is really the best solution long-term.

Realize that you can't keep piling new, incompatible features into the
existing pile-of-crap ORBit 0.5.x. I don't care whether you want ORBit2,
ORBit HEAD, or whatever as the long term solution, it's better to work on
the long-term solution than find creative ways to fit new features into
the old codebase without breaking existing apps. Then when people move to
a new major version, you can comfortably make the requirement that they
fix their broken apps. Yes, people using the old version are going to
suffer from the limitations of its API, but those limitations are not new
or anything...

Dunno, I just prefer to avoid cruftiness as much as possible. Opinions
welcomed.
-- Elliot
The truth knocks on my door, and I say
"Go away. I'm looking for the truth"
...and so it goes away.