[dev] [commits] Horde branch develop updated. fa956a4d83a7227e2a5d47bfe87185854e151fbc

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Maybe what this boils down to is that the initialize() code needs  
>> to be cleaned up immediately.  Most of the stuff in there can be  
>> refactored to either load-on-demand or be initialized once and  
>> cached in the session.  You are going to see a giant speed boost  
>> when this happens.  I would even say this is the single most  
>> important feature that Kronolith 3.1 can offer.
>
> I don't disagree with you about ::initialize(), but what I said in  
> my other email still stands; The changes to notification  
> initialization in Core will break synchronization to existing  
> Kronolith installations - or any RPC access that requires access to  
> a calendar - if Core is updated and Kronolith is not. That's a BC  
> break.
>
> I'll step out of the thread now, and let you and Jan decide if this  
> is actually to be considered breaking BC or if it can be called a  
> "bug" in kronolith that necessitates updating kronolith to fix.

To me this is clearly a BC break. It doesn't matter much if the  
original intention of _init() was different. Fact is it behaved  
consistently for the complete H4.0 life cycle.
And I would be surprised if it doesn't affect more applications.  
Especially if I think of the complex share initialization in Turba.

-- 
The Horde Project
http://www.horde.org/