Interesting point Dan - However we also have to weigh what code sharing
brings to development and maintainability of Derby and especially in
the long run versus the patch shadowing issue in particular application
environments which does *not* seem to me like the most majority of
running configurations today (being more like corner case ones) or even
in the future (95/5 rule let's say) I could be wrong of course - I'm
already seeing some discrepancies in the codeline with pieces of code
containing similar logic but where changes (patches) have been applied
to one side and not the other - Yes this is not supposed to happen but
it does happen and I think it is bound to happen even more within a
community (as more contributors come onboard). So, not providing code
sharing can also lead to not propagating code changes in various places
throughout Derby where similar piece(s) of logic have been duplicated -
I also believe that the redundancy of piece of logic can only get worse
along the years if there is no code sharing (since we would keep on
adding redundant pieces of logic between the client and embedded engine
instead of sharing whenever it makes sense).
I understand the issue with patch shadowing and I think it is a valid
one but when I look at it at not being the majority of applications
running Derby out there (I may be wrong again).
We could rather document on how to address some *potential* issue that
might arise with a 5% of running configuratoins out there versus
sacrificing maintainability of Derby in the long run. But this is
*only* my personal point of view from my own perspective and context -
Support might have a different point of view but code sharing also aims
at improving quality of the code in the long run IMHO which will
benefit Derby users as well..
Cheers,
--francois
On 10/28/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
I don't think anyone is saying that shared code has to fix every
mismatch, but the real point is, do we want to (potentially) regress in
this area?
Dan.
