Hi devs, has there been any thought to using interfaces/implementations for some of the rc elements? For instead, i was looking into the work it would require to support redis as a session storage (because it's persistent and memcache isnt), but it looks like db/memcache are pretty hardcoded and intertwined in the code. It would be so great if the session store was an interface with a few implementations. Hell, we could have plugins implementing interfaces.
The same probably goes for other elements of roundcube like addressbooks.
Cor
On 05/29/2014 10:50 AM, Cor Bosman wrote:
Hi devs, has there been any thought to using interfaces/implementations for some of the rc elements?
Personally I don't like too much files in a framework, so I don't like interfaces. However, I think we could split session class by driver, i.e. rcube_session for default php sessions and as a parent for rcube_session_db, rcube_session_memcache (and others).
The same probably goes for other elements of roundcube like addressbooks.
rcube_addressbook is already an abstract class and that's fine.
On 02 Jun 2014, at 10:55, A.L.E.C alec@alec.pl wrote:
On 05/29/2014 10:50 AM, Cor Bosman wrote:
Hi devs, has there been any thought to using interfaces/implementations for some of the rc elements?
Personally I don't like too much files in a framework, so I don't like interfaces. However, I think we could split session class by driver, i.e. rcube_session for default php sessions and as a parent for rcube_session_db, rcube_session_memcache (and others).
That would work as well.
As a side note, I dont agree with you regarding the number of files. On systems where this truly matters, surely everything is cached in disk and/or op cache. I think you wont see any noticeable difference in performance between opening 50 files or opening 100 files. It will be measured in a few ms. The roundtrip to the imap servers is going to be factors slower. Ok, maybe if you run your rc instance in a slow VM you'll notice.
But anyways, it doesnt matter, an extended class would be cool too. (although, arent you opening the same number of files then?)
Cor
On 06/02/2014 11:06 AM, Cor Bosman wrote:
As a side note, I dont agree with you regarding the number of files.
I wasn't worried by a performance impact. I worked with frameworks that used a lot of interface/abstract/watever classes and found reviewing the code harder, but maybe that's a matter of experience.
But anyways, it doesnt matter, an extended class would be cool too. (although, arent you opening the same number of files then?)
The number of files will be lower as there will be no interface class, and actually there might be no abstract class either in this case. ;)
-
A.L.E.C -
Cor Bosman