Hello devs
Regarding the feature request in ticket http://trac.roundcube.net/ticket/1488294 I'd like to discuss the proposed change here. While I totally understand the concern about copying the complete data structure for contacts and groups for every plugin which adds a new address source to Roundcube, I still fear that such a change will make it harder for the core development to deploy changes to these tables once 3rd party components also make use of it. We'd like to stay autonomous and our only concern should be to keep the plugin API backwards compatible.
In my opinion, every plugin which doesn't directly operate on the internal address book data should build up it's very own storage. If it's a remote address book for example, one could make use of the new rcube_cache class to maintain a local copy in order speedup reading and writing. But maybe I'm wrong with this...
Any votes or arguments for or against the proposed change?
Best, Thomas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 01/07/2012 01:58 PM, Thomas Bruederli wrote:
Regarding the feature request in ticket http://trac.roundcube.net/ticket/1488294 I'd like to discuss the proposed change here. While I totally understand the concern about copying the complete data structure for contacts and groups for every plugin which adds a new address source to Roundcube, I still fear that such a change will make it harder for the core development to deploy changes to these tables once 3rd party components also make use of it. We'd like to stay autonomous and our only concern should be to keep the plugin API backwards compatible.
In my opinion, every plugin which doesn't directly operate on the internal address book data should build up it's very own storage. If it's a remote address book for example, one could make use of the new rcube_cache class to maintain a local copy in order speedup reading and writing. But maybe I'm wrong with this...
I think the same. Also our UI doesn't allow cross-source groups.
-
A.L.E.C -
Thomas Bruederli