Loading...

dev@lists.horde.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [dev] [commits] Horde branch develop updated. fa956a4d83a7227e2a5d47bfe87185854e151fbc Jan Schneider Tue Feb 14 07:00:48 2012


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]