[dev] [commits] Horde branch master updated. 549a1a57841717f032d1d95e86d10679297356e1

Gunnar Wrobel p at rdus.de
Sun Sep 12 10:36:00 UTC 2010


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

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Gunnar Wrobel <p at rdus.de>:
>>
>>> commit 549a1a57841717f032d1d95e86d10679297356e1
>>> Author: Gunnar Wrobel <p at rdus.de>
>>> Date:   Mon Aug 30 09:12:59 2010 +0200
>>>
>>>   Added the Interfaces package.
>>>
>>>   Rationale:
>>>
>>>   When looking at the Kolab_Session package I realized that
>>>   "Horde_Auth::getAuth()" calls have been converted to
>>>   "$GLOBALS['registry']->getAuth()". While this may be fine on the
>>>   application level I don't think it is acceptable on the level of a
>>>   framework package.
>
> This change was not meant to be permanent - it was only meant to  
> allow the packages to continue to work while we move them over to an  
> injectable framework.

Ah, good to know. So will this move back eventually?

>
> See, e.g., the Auth or Identity factories for examples on how to  
> inject a username into a package.
>

As far as I can see both use the getAuth() call from the registry to  
get the user information. Or did I misunderstand you?


> And if a certain library is so tied up in authentication related  
> stuff, it should be living in Core (or, at worst, in a separate  
> package that has a required dependency on Core).

Agreed. The getAuth() function is rather trivial though and if I  
understood your comment from above correctly then it does not  
necessarily need to live in Core. I would assume that it is sufficient  
to define a package that knows how Horde authentication information is  
being stored in the session storage. Which the "Auth" package did  
before.


> For Kolab stuff, I would imagine this might be the best tactic - or  
> is the expectation that the Kolab-Horde integration code will be  
> used in areas outside of just installing Horde applications?

All the other components are being used in  
non-Horde-application-context (which is why this PEAR packaging of the  
framework is so important to me). The Kolab_Session package is the  
only one I solely use on the application level at the moment. It  
stores additional user information in the session so that I don't have  
to call LDAP for this. So currently a dependency on Core might  
actually be okay. But in the long run it could of course still happen  
that I have to use this code in a non-Horde context if the Kolab  
community decides to move away from Horde. Of course my job is to try  
to avoid that :)

Anyhow: For now I can check if I actually need the sanity check that I  
use the auth information for. If not, I can revert this.

Or - if you tell me the method will be moved out of Core soon - I  
could revert then.

Cheers,

Gunnar

>
> michael
>
> -- 
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>







More information about the dev mailing list