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

Zitat von Michael J Rubinsky <[EMAIL PROTECTED]>:

> Quoting Michael M Slusarz <[EMAIL PROTECTED]>:
>
> > 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/

--
Horde developers mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [EMAIL PROTECTED]