[dev] Horde_Share_Base::listShares()

[Michael Rubinsky]

Quoting Gunnar Wrobel <wrobel at horde.org>:

>
> Zitat von Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>>>>
>>>>> Hi!
>>>>>
>>>>> The function mentioned above does support several sorting/paging  
>>>>> features ('from', 'count', 'sort_by', 'direction'). As far as I  
>>>>> can tell none of these parameters are actively used within our  
>>>>> code base (with the exception of 'sort_by' but 'name' seems to  
>>>>> be the only setting used here). Currently only the Sql-Drivers  
>>>>> supports these features and I wonder if we really need them.
>>>
>>> Huh. That's embarrasing. I'm pretty sure it worked at one point,  
>>> but maybe that was back in the DT days. I never realised that the  
>>> paging parameters were ignored by the SQL share drivers.
>
> They don't. As mentioned in my original mail the SQL drivers are the  
> only ones that actually support it. It does not work within the  
> Horde_Share_Base::listShares() but that only applies to the Datatree  
> and Kolab drivers.

Ah. Ok. I apologize, I misunderstood what you were saying, and I don't  
have access to the code at the moment to look. At least now I don't  
think I'm losing my mind :)


> Two additional questions though:
>
> 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.

Originally, when hierarchical support was removed from DT for  
performance reasons, Ansel had kept it's own share driver, then when  
Duck started work on the SQL share driver, we kept the hierarchical  
driver seperate both for performance, and to keep the SQL driver as  
simple as possible, since none of the other apps need hierarchical  
support.

There are some other differences, there are no share_names in the  
hierarchical driver; share_ids are used for everything. There is no  
need for the names, and causes confusion (though that's probably just  
my feeling based on bad experiences with this while adding initial  
share support to Turba - the code has significantly improved since  
then). I also don't want Ansel's galleries to have to be identified by  
these string hashes, it would break existing permalinks, makes for  
long ugly urls, and would probably require some refactoring in  
Ansel...not that refactoring is "bad", just sayin'...

If it's possible to combine them without complicating things too much,  
degrading performance, and keeping the above mentioned points about  
share_name vs share_id intact, that's fine with me.

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

I have questions about this, but want to look at the code first to  
gather my thoughts...I'll reply after I get back in front of my  
computer and review :)

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin