ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafal Rusin <rafal.ru...@gmail.com>
Subject Re: [VOTE] Include event_handler_1x.patch into ODE-1.X
Date Fri, 06 Nov 2009 21:07:17 GMT
2009/11/6 Karthick Sankarachary <sankarachary@intalio.com>:
> Rafal,
> To mitigate against any potential compatibility issues, I suggest that you
> write the OutstandingRequestManager such that it works even if the new field
> that you added (i.e. _replyRid) has not been initialized. Specifically, if
> that field is null you probably want to assume that there's no reply
> corresponding to the entry in question. This sanity check will help ensure
> that instances started prior to the upgrade do not break down due to this
> change in the process model.

OK, this sanity check looks easy to do. I can add that. But handling
all potentially broken cases in modified OutstandingRequestManager or
adding new class OutstandingRequestManager2 + iffs around code, would
be bad I think.

What I want to achieve with this vote is to see committers' and users'
opinions on backward compatibility for instances. Because I don't
believe that users care much for upgrading ODE from 1.3 to 1.4 with
holding their old binary instances.
As for me, I prefer more clean code, which is quite messy in some
places for now in ODE. And as for migration, I think it may be solved
some time in future by implementing export/import to/from xml
Similar thing is for ODE trunk. There are two packages for runtimes v1
and v2. I think it's a very bad solution for providing backward
compatibility, because it's a full duplication of code. I would prefer
to not provide backward compatibility and have only one runtime.

Well, if your opinion is opposite, please don't hesitate to vote -1.
It's just a simple voting, no offense at all.

RafaƂ Rusin

View raw message