[dev] [cvs] commit: genie item.php wishlists.php genie/lib Genie.php base.php genie/po genie.pot sl_SI.po genie/templates/wishlists shared.inc

[Chuck Hagenbuch]

Quoting Duck <duck at obala.net>:

> On Thursday 20 of December 2007 22:11:19 Chuck Hagenbuch wrote:
>> > For example, by just accessing the their wishlist
>> > genie created 3,075 shares, but only 233 users have actually entered
>> > their whises. So I would have a lot of shares to be loaded (slower sql,
>> > bigger ram usage, longer loops). As Genie now is PHP5 I beleive that we
>> > should allow this approach for Horde4 or even encourage it. I have 58K
>> > ram usage just for loading the (mostly empty) wishlists. Multiplying form
>> > the number of users I have online (from 1.000 to 1.500) current approach
>> > is really problematic as I often fall even in maximum execution time in
>> > Shares or DT.
>>
>> Isn't the solution here the datatree replacement? If you need this
>> now, I'd suggest focusing there (Horde_Tree should be expanded with
>> backends for storing/reading trees and the current code in renderers
>> or Horde_View helpers).
>
> I am forced to do this. As my wishlists grown over 5.000 and with the current
> architecture I cannot even retrieve them.

I appreciate that, and that you're pushing the Horde infrastructure  
harder than some people are, and you're trying to improve it. Which is  
awesome. But it doesn't mean that all of your local changes are right  
for Horde CVS.

Also, it sounds like with the new Share driver you have, this could  
probably be restored?

> So I should focus on horde_tree... Should I try to solve this particular
> problem or do it in a more general way to allow later share replacement
> globally? Are there any particular things I must have in mind here?

The specs we've been aiming for for the new share driver are:

- doesn't have to handle hierarchies (I'm hoping we can intersect a  
list of shares matching a permission with a separate tree structure  
with good performance, to handle apps like Trean and Ansel).

- try to standardize on the id field, although for backends like Kolab  
we need to allow ids to be strings

- there is a set of standard data that should be stored as real  
fields, and additional fields (custom share attributes) can be a  
serialized text field. I think the list is name, owner, and the  
permissions, but I might be missing one or two.

- horde_tree would contain backends for that other hierarchy management

I know you wrote this a while ago and have worked on the SQL share  
driver since. Where does that, plus my feedback here, leave you/us?

Thanks,
-chuck