cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Compatibility Issues with 2.2
Date Fri, 05 Dec 2003 20:17:49 GMT

On 4 Dec 2003, at 02:22, Unico Hommes wrote:

>> -----Original Message-----
>> From: Carsten Ziegeler []
>> Sent: donderdag 4 december 2003 11:03
>> To: Cocoon-Dev
>> Subject: Compatibility Issues with 2.2
>> I'm a little bit concerned about compatibility between 2.1 and 2.2.
>> Now, imho every component developed for 2.1 should also work in
>> 2.2 without requiring to change the code - recompiling is acceptable.
>> There are of course two exceptions to this rule:
>> a) if you are using deprecated code
>> b) if you are using some private code/internals that you
>> shouldn't have
>>    used.
>> Now with this great move to fortress we changed Composable to
>> Serviceable and Recyclable to Resettable. The first move
>> (C-->S) has been done in a compatible way as we introduced
>> new abstract classes that replace the "composable" abstract
>> classes with "serviceable" versions.
>> That's ok.
>> But, the move from Recyclable to Resettable has not been done
>> in this way and will break a lot of components! E.g.
>> AbstractXMLProcuder has been changed from Recyclable to
>> Resettable, so every component inheriting from that one will
>> break! That's bad.
>> I really think this move Recyclable to Resettable is
>> nonsense. It has no advantage (while Composable to
>> Serviceable has). It's only this "we need to choose the
>> correct name" thing.
>> Now, Fortress must support Recyclable anyway - otherwise it'S
>> not compatible to ECM (I guess Fortress does so anyway), so I'm
>> +1 on still using Recyclable. This is a) more painless and
>> b) more compatible.
>> WDYT?
> +1
> I never understood why Resettable was introduced in the first place,
> aren't its semantics exactly the same as Recyclable? Why are Ressetable
> or Recyclable not part of the core framework? Even if we move to
> Resettable now, nothing will insure that the next big container will 
> not
> introduce yet another interface for the same functionality

+1 as well. These name/concepts dances in Avalon just make me oscillate 
between angry and sad.

Guess what happens to those who seek perfection: they fail, like 
everybody else. But they spend much more time failing than those who 
know they will and stop at the "worksforme" level.

But what do I know...

> --

View raw message