[dev] Horde_Share_Base::listShares()

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at horde.org>:

> 1) Why do we have a separate Sql and Sql_Hierarchical driver?  
> Wouldn't it make sense to collapse the two and always be  
> hierarchical? I'd have no problems supporting a tree structure with  
> the Kolab driver. In fact I'd like to do that.

I'm all for it, if it makes sense for Michael.

> 2) Can we move the handling of credentials into the backend? I admit  
> I didn't go through the full Share code yet so I might not know all  
> implications of this. But my impression so far was that the Sql  
> driver operates in "Admin" mode. It has full access to the DB and  
> can do things like listAllShares() - independant of the permissions.  
> On the other hand listShares() needs a specific user ID. I'm unable  
> to support this scheme with the Kolab backend. Simply because ACLs  
> are *always* applied in the backend. The IMAP connection has been  
> authenticated for a specific user and I'm not able to escape the  
> boundaries of this user. I could of course list all shares on the  
> server but I would have to authenticate as "manager" (or whatever  
> the root/admin IMAP account is named) to the server. I don't mind  
> the listAllShares() method so much but I would like to get rid of  
> the $userid parameter in listShares().

IIRC we are using the parameter actively in a few places, e.g. for  
sending calendar agendas. I'd rather avoid instantiating a new Share  
object each time.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/