[dev] [commits] Horde branch master updated. bb85601da508e3272d0f9bda00310c28f278e86c

[Michael M Slusarz]

Quoting Michael Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> I will say I disagree with the speed of the release (me  
>>>> complaining about release speeds?  The world has gone crazy).   
>>>> We've been working on the H4 for essentially 4-5 years now.   
>>>> We've had betas/release candidates out for about a month.  With  
>>>> this increased usage of these release candidates due to the  
>>>> testing releases, the amount of bug reports/fixes has exploded.   
>>>> The increased eyeballs/usage is invaluable.  I don't feel like  
>>>> these reports have tapered off over the course of the release  
>>>> cycle (yet).  It seems to me that we stability of a release is  
>>>> more important than a firm date.
>>>
>>> I guess I'd ask if you're worried about things that would  
>>> potentially require backwards-incompatible changes right off the  
>>> bat? If not, then I definitely vote for pushing ahead - if the .0  
>>> is a little buggy, well, everyone expects that and we can improve  
>>> it quickly.
>>
>> Gunnar pointed out flaws in the Mime_Part code that will only be  
>> fixable with BC-incompatible changes (I think).  The good news is  
>> that it doesn't affect anything we currently use Mime_Part for.  So  
>> this could probably wait until 4.1 (or however we are going to do  
>> this).
>>
>> But other things like the behavior of prefs_init.  There's a bug  
>> open (#9728) where a user is trying to using application methods to  
>> set prefs values.  But prefs_init is called BEFORE an application  
>> is ever initialized (for obvious reasons) so any application method  
>> that relies on things like session variables will not work  
>> properly.  Not sure if this is a documentation issue, a design  
>> issue (although I am 99% sure this is the way prefs hooks worked in  
>> H3 - not sure how they could work otherwise), or something else.
>
> FWIW, what this person is trying to do did not work in Horde 3  
> either. I'm not sure off hand what would need to call an Application  
> method (not in front of code at the moment), but the share system  
> must be available and useable in order for this to work since the  
> source key ("localsql" in this case) for the source's entry into  
> $cfgSources[] is replaced by share identifiers during init. I can  
> look into this further, but unfortuanatly probably not until Tuesday  
> afternoon.

See Bug #9728.  This is definitely a documentation issue.  To do what  
the person in the Bug is trying to do requires something like the  
postauthenticate pref instead.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]