[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

[Michael Rubinsky]

duck wrote:

>> mike wrote:
>> Wouldn't we have to make assumptions about how the perms are stored?
>> This would assume that perms are always stored in SQL, plus, I don't
>> see how we could merge perms data with application specific data in
>> the same table without giving each application it's own perms driver.
>> Or am I missing the boat here on what your trying to say?

> The only thing we must do is to give each application its main  
> table, that can be added to the application sql creation script.  
> Permission or attributes are not problem as driver will handle them  
> transparently. We are not changing the share API but creating a new  
> driver. The only addition it will be the array share list method,  
> mentioned in of my previous mails.

> Looking at Ansel again, attributes will go back inside shares. You  
> can easily use DT  (or Kolab, even I don't see how someone will like  
> to use Kolab for galleries) for small installation or pass to SQL  
> for large data.

> I don't know if you  took a look at my proposal (#6109), maybe not  
> ideal but is a big performance bust without changing any application  
> code. It misses only the hierarchies.


Yea, I did take a cursory look at that and it does look promising and  
I can see how this could be a huge performance improvement. The issues  
that I see are:

1) No hierarchies, so we would still need an additional storage  
mechanism for that...although I know you said you would be working on  
that.

2) In Ansel's specific case, adding the gallery properties back into  
share storage would create difficulties with how the tags work.  One  
of the reasons I felt strongly about having a gallery specific table  
was that I didn't like directly querying the datatree table without  
going through datatree/share object.  We'd have to go back to quering  
the shares table directly if we got rid of the gallery table...and  
*that* would be making assumptions about what type of storage we have  
for the Shares api...or at the very least would dictate that we must  
use sql for apps such as that.

Plus, I guess I'm still being thickheaded/stubborn about putting data  
related to something other than permissions/share data into share  
storage.


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

"Time just hates me. That's why it made me an adult." - Josh Joplin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
Url : http://lists.horde.org/archives/dev/attachments/20080123/d8dc4b06/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: PGP Digital Signature
Url : http://lists.horde.org/archives/dev/attachments/20080123/d8dc4b06/attachment-0001.bin