[dev] Horde_Share_Base::listShares()

[Michael Rubinsky]

Quoting Michael Rubinsky <mrubinsk at horde.org>:

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

Ok. Now that I've spend some more time with the code, the only  
remaining reason (beside any potential performance issues related to  
the longer share_parent fields) to really keep them separate would be  
to maintain using share_ids as identifiers in Ansel. If we combine the  
drivers, we'd need to use the share_names to identify the galleries,  
which would lead to existing links to galleries being broken.  We'd  
also obviously need to run some data conversions on all the ansel  
tables - and the gallery key image code would need some refactoring  
(since it uses negative gallery-ids to indicate they are key images).

I've thought some more about my objections to this, and I think I'm  
more ok with this now, if it means a more consistent interface for the  
share package.

What does anyone else think about this? How important is keeping  
existing URLs that may have been posted out in the wild?

mike

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