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/
Hi,
Just installed RC. Love it, but found a 40-50 missing entries in the Danish
language file. I've added them with the translate-o-matic script on the
site, and attached it. Enjoy.
Cheers,
HC
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/tR/tRpc6VYj/labels.inc
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi,
I've translated RoundCube 0.2beta to Cymraeg (Welsh) - cy_GB
I'm attaching the translation files. I've tested these on my
local copy and looks sensible so far. I'd suggest 'Cymraeg'
as the label in the options.
Any intention to move to .po files for translations? There
are a lot of tools for gettext catalogs to make translation an
easier job.
thanks
Dafydd
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/d6/zurcd6QG/cy.zip
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi everybody,
I posted a patch 2 months ago (http://trac.roundcube.net/ticket/1485274)
I update it as regular bases to avoid conflicts, but it seems that nobody
cares about committing it :-(
The patch enables USB dongle hardware authentication, it has already been
integrated in other open source projects (squirrelmail, phpMyAdmin,
phpBB...)
I already sent free swekey USB dongles to some you to validate the patch,
but I didn't receive any feedback.
Did I miss something in the roundcube project's policy ?
Cheers,
Luc
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi everybody,
I posted a patch 2 months ago (http://trac.roundcube.net/ticket/1485274)
I update it as regular bases to avoid conflicts, but it seems that nobody
cares about committing it :-(
The patch enables USB dongle hardware authentication, it has already been
integrated in other open source projects (squirrelmail, phpMyAdmin,
phpBB...)
I already sent free swekey USB dongles to some you to validate the patch,
but I didn't receive any feedback.
Did I miss something in the roundcube project's policy ?
Cheers,
Luc
_______________________________________________
List info: http://lists.roundcube.net/dev/
Daniel Mealha Cabrita wrote:
> Thomas,
>
> I've sent an email on this very subject to the devel mailing list,
> unfortunately I've got no response.
I'm sorry for that but I cannot answer every post there. Don't expect your
mails being answered within a couple of days.
>
> Since you're the author of that code, there are some things I would like to
> ask you about rcube_ldap.php.
Well, others had implemented a lot of functions as well. I'm not very
experienced with LDAP even if my name is found in that file.
>
> I'm copy-pasting the original message I sent to that list:
>
>
> ---
> I've been implementing an extension to RC which may use LDAP (depending on how
> it was configured).
>
> There's already the
> include/rcube_ldap.php
> which _seems_ to present itself as a generic interface to LDAP.
>
> One problem is that it was implemented with addressbook in mind, so there are
> lots of fields and behaviors which are useless in other cases when accessing
> LDAP.
Correct. What do you wanna use it for?
>
> The code I'm working on is intended to be integrated into the main tree of RC
> (so it's not supposed to be just a quick'n'dirty patch).
> With that in mind, I have two questions:
>
> 1. - Is the rcube_ldap class really the standard one for other
> (non-addressbook) LDAP accesses?
No.
> 2. - If "yes" to #1, how is the "standard" way to use that to avoid future
> code breakage? (a code example would be nice)
> 3. - If "no" to #1, what could be an acceptable solution? A parallel and more
> generic LDAP class implementation?
I don't unferstand what you intend to do with LDAP and therefore I cannot
answer that question.
~Thomas
_______________________________________________
List info: http://lists.roundcube.net/dev/