[dev] Horde_Share_Base::listShares()

Chuck Hagenbuch chuck at horde.org
Fri Jan 14 14:57:01 UTC 2011


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.
>>
>> Horde_Share_Base::listShares() is fully replaced within  
>> Horde_Share_Sql and Horde_Share_Sql_Hierarchical. For  
>> Horde_Share_Kolab and Horde_Share_Datatree  
>> Horde_Share_Base::listShares() is called which delegates to  
>> Horde_Share_{Datatree,Kolab}::_listShares(). The sorting/paging  
>> apparently should be handled within Horde_Share_Base::listShares()  
>> for these drivers. The current implementation is incomplete however.
>>
>> I don't mind completing the implementation if necessary but there  
>> are some things that currently puzzle me. Assuming a user has a few  
>> thousand shares and we would use the paging feature for example:  
>> Wouldn't the current Horde_Share_Sql:listShares() quickly fill the  
>> Horde_Share_Base::_listcache with plenty of caching information  
>> that gets stored in the session? For every sort setting it would be  
>> the same thing. I also wonder a bit if that is actually information  
>> that should go into the session at all.
>>
>> On the other hand there has been a lot of work put into the Share  
>> driver recently and as far as I understand it there is more to  
>> come. I just wanted to get some feedback to understand where this  
>> is heading and if I should ignore the topic for now.
>
> If we don't use some of the paging/sorting features and don't come  
> up with any use case for it (and honestly, who is going to have such  
> a huge load of shares?), I'm fine with removing them to reduce  
> complexity.

The features are likely for Ansel and Trean. I'm all for reducing  
complexity there, though.

-chuck


More information about the dev mailing list