[RCD] structural change proposal and LDAP issues

[Daniel Mealha Cabrita]

hi there,


There are some changes I find appropriate to do regarding the classes, which 
are stored in the include directory.
The motivation is to improve the modularization _and_ to avoid flooding the 
include directory with dozens of small files.

I've got features which use LDAP (yet structurally extensible to additional 
mechanisms) and I need a more basic and standard LDAP class for that.


1. - I'm currently splitting the rcube_ldap class in two:

1.1 One specific to the addressbook feature (with the very same behavior as 
before), with inheritance from the classe described in 1.2.

1.2 - Another one being a superclass, for generic ldap access.


>From what I could understand on the philosophy of the classes used in RC, 
although we may have several classes in the same file, only one is supposed 
to be externally accessible (and it seems that the filename itself is used to 
determine which one).
Once we start modularizing things (like allowing a different mechanism for 
external addressbooks, instead of only LDAP as currently it is), if we follow 
this logic we may end with too many files.


2. Now about what I am proposing.
I'll give an example which, hopefully, will clarify what I have in mind:

2.1 - To create a new rcube_ldap.php file with a generic LDAP class only (yes, 
addressbook code would have to the moved to another place, or we could call 
the former rcube_ldap_generic.php to simplify the transition).

2.2 - A rcube_XYZ.php file providing a specific feature (addressbook, user 
identity etc). In that same file there are additional classes providing 
services according the mechanism chosen (LDAP etc). This file would have the 
XYZ-specific code when dealing with LDAP (through the generic LDAP class) and 
any other mechanism which could be added in the future.


It _seems_ to me that the current philosophy expects the item 2.2 to be broken 
in two or more pieces, from what I see no practical benefit (and it would add 
lots of files once we start to support extra mechanisms).
If my understanding is incorrect on this, please someone tell me so.


Comments?
Suggestions?

-- 
 Daniel Mealha Cabrita
 Divisao de Suporte Tecnico
 AINFO / Reitoria / UTFPR
 http://www.utfpr.edu.br
_______________________________________________
List info: http://lists.roundcube.net/dev/