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

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> 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.

Well, I would argue that determining what calendars are available for  
use in Kronolith is a pretty fundamental requirement of any kronolith  
action, so even if we buy in to what you say in the above paragraph,  
this still belongs in _init().

> (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.

The whole reason I discovered the problem is because of the change in  
Core breaking the existing behavior of Kronolith.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6096 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20120213/0c1b971b/attachment.bin>