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

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

>> This is currently broken though, because Kronolith::initialize() is  
>> where we determine what shares (and other, non-share based  
>> calendars) are available. I just tested this, and in fact the  
>> sidebar does not contain the calendar list when viewing the horde  
>> portal.
>>
>>> _init() is for bootstrapping only.  You can't call  
>>> registry/horde-wide things in there due to the chicken/egg  
>>> problem.  _init() is not designed to set up the full application  
>>> environment.
>
> But we have been using it for exactly that since Horde 4. We cannot  
> simply change the semantics of an API method because it doesn't work  
> anymore after some refactoring in Horde or Horde_Core.
> _init() has always been the place to set up the app environment  
> since we dropped base.php.

Except this is *exactly* how we've been using it.  And it is exactly  
what the API says it should be used for:

Does any necessary init needed to setup the full environment for the  
application.

Full environment meaning enough to load the application.  Not to load  
**EVERYTHING** the application may eventually need to possibly use on  
a page.  See, e.g., IMP which does nothing in _init() except load the  
basic environment.

(As mentioned in the previous post, Kronolith breaks a bunch of stuff  
in 3.0 because it is doing things like overwriting Horde global  
variables in _init().  Not good.)

>>> So that does mean that the timezone stuff needs to go someplace  
>>> else.  Maybe Kronolith::initialize()?  But it can't be done in  
>>> _init().
>>
>> Ok, so then the solution is to refactor again to remove  
>> Kronolith::initialize() from _init(). It was nice to have it done  
>> in one central place, but I'm seeing that this is not going to be  
>> possible with the current way apps are initialized.
>>
>>> The linkTags() can stay as-is for now - it is only used if  
>>> Kronolith is the current active application.
>>>
>>> All of this came to light a few weeks ago when doing some  
>>> xdebugging.  In so many words: the SAPO folks were not very happy  
>>> at all to see that a large portion of a page access for things  
>>> like viewing a message were being spent in kronolith (or, more  
>>> broadly, any application), even if NOTHING on the page ever  
>>> directly accessed those applications.  I agree.  The two culprits  
>>> were application notification handling and alarm checking.
>>
>> Agreed, though don't the changes in Core border on a BC break since  
>> updating Core without updating Kronolith would lead to broken RPC  
>> usage, including SyncML and ActiveSync?
>
> Agreed.

How so?  Horde Core reverts back to the old behavior for checking on  
every pageload for notification and alarm checking if the applications  
haven't been update to use the newer version of Horde Core.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]