Dev

dev@lists.roundcube.net

2 participants
4301 discussions

Plugin-Architecture
by Florian Lagg 07 Aug '08

07 Aug '08

Dear Developers! I am using RC in my hosting offers and I want to implement two things: * a kind of plugin-mechanism: It should be possible to "register" some external plugins to events (User login, handling contact data, ...) * a Funambol-Plugin (as seperate open source project): Funambol is a server capable of syncing contacts/calendar items between native Clients (Outlook, Thunderbird), various Devices (many mobile phones, PDA's, ...) and other webmail-applications and groupwares. I talked to A.L.E.C. some days ago because he had plans for the plugin infrastructure. According to his mails he has no time to develop this in the near future and I asked him if I can do the work. He answered it would be ok, so I'll ask you how it should be done: So here are my questions: * How should a plugin-architecture be implemented in RoundCube? Maybe my approach is completely wrong, just tell me if you think so... I'm thinking of a PluginHooks singleton class which is called from various points in the existing source code. This class reads a config file if there is a plugin registered for the specific event. This config contains a line for each event like this: $rcmail_config['pluginevent_userlogin'] = array('Funambol'); //registers a single plugin called "funambol" for the event "userlogin" $rcmail_config['pluginevent_nextEvent'] = array('Funambol', 'AnotherPlugin); //call two plugins in the given order PluginHooks then initates a class Funambol (located in RC_Home/plugins/Funambol) and calls a method pluginevent_userlogin. Because PluginHooks is a singleton, it could provide methods to the plugins to get or manipulate data from the rest of RC. so anything is handled over this class. I hope I discribed it well. Please bring your own ideas if you have better once. * Is anyone interested in teaming up? * Is anyone willing to implement plugins in near future? If so - please talk to me to discuss your requirements to make this project as useful as possible. You can send me a CC so I can answer your mails quicker. Thanks in advance, Greetings -- Florian Lagg - Florian Lagg - IT-Komplettlösungen Juch 7, 6631 Lermoos tel +43 (699) 10 20 10 24 <http://www.lagg.at/> www.lagg.at - <mailto:info@lagg.at> info(a)lagg.at - Xing: <http://www.xing.com/go/invite/7372113.3da562> http://www.xing.com/go/invite/7372113.3da562 - _______________________________________________ List info: http://lists.roundcube.net/dev/

4 8

Re: [RCD] Plugin-Architecture
by Florian Lagg 07 Aug '08

07 Aug '08

> Michael Baierl wrote: > > There is a convention - an parameter array for receiving data ("named > > parameters") and returning data as an array. Done. Never touch the input > > array. > > This rule is relatively easy to check during QA and it is easy to use > > and developers are used to that. > > > > Every class you create has to be understood and makes stuff more > > complicated. KISS. > > > Amen! I only belief to RFC! But I am convinced. Thanks for all comments. I'll go on with arrays. Again: because of lot work I will be able to show a second prototype in 2 weeks or so. I have one important point left we should discuss: (I know, I can be annoying) What do we need to implement the plugin-arch in the frontend part, such like in A.L.E.C.'s list: > Typical plugin needs are e.g. adding a button in tasklist, adding a tab > in Settings interface, adding a configuration option in User Preferences > (simple tasks, just for start). I have no insight of the frontend in RC and I do not want to develop these things right now. But I need to know how they work that anyone can implement these things later without rewriting my code. I asked jeroen for his sieve patch (to find it out myself) but I havn't got it so far. Anyone? -- Florian Lagg - Florian Lagg - IT-Komplettlösungen Juch 7, 6631 Lermoos tel +43 (699) 10 20 10 24 www.lagg.at - info(a)lagg.at - Xing: http://www.xing.com/go/invite/7372113.3da562 - _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

spell checking
by Kris Steinhoff 07 Aug '08

07 Aug '08

I'm curious about the behavior of the spell checker. If HTML is set as the default editor, then when the compose screen is first opened the spell check controls don't appear. When editor type is switched to plain text, the controls appear, but when the editor type is switched back to HTML, the controls stay put and behave in peculiar ways. Should the spell checker be active while using the HTML editor? thanks -kris -- Kris Steinhoff Web/DB Team, Information Technology Central Services The University of Michigan _______________________________________________ List info: http://lists.roundcube.net/dev/

2 1

Re: [RCD] imap_root patch (significant speedup)
by ziba 07 Aug '08

07 Aug '08

Hi Raoul, Thanks for the feedback. At least in svn, rcmail::get_instance()->config->get('imap_root') will return null if there is no imap_root configuration variable. So roundcube keeps on ticking. I'm also uncomfortable using globals the way iloha uses $my_prefs. However, from what I could see, that's just how iloha works. It looks like a choice between using some undesirable global variable "action at a distance" or modifying the iloha's imap library. Modifying iloha wouldn't be hard, but it looks like developers have avoided putting roundcube configuration specific code into iloha so far. Cheers, Ziba -- Ziba Scott Web Application Developer Web/DB Team, Information Technology Central Services The University of Michigan On Tue, 05 Aug 2008 11:21:59 +0200, "Raoul Bhatia [IPAX]" <r.bhatia(a)ipax.at> wrote: > hi ziba, > > Ziba Scott wrote: >> Hi, >> We're testing roundcube in a fairly large environment (80K users, 900K >> mailboxes) with a cyrus imap backend. In our environment, >> roundcube/iloha imap's namespace discovery phase takes about 1.5 seconds >> on an unloaded machine. This happens on every email view. >> >> Iloha has the ability to skip the namespace discovery phase if a >> imap_root is configured and roundcube has a configuration option for >> imap_root. But the two aren't connected! By handing off the imap_root >> variable to iloha mail sooner rather than later we cut our time to view >> a message from 1.7 seconds to 0.2 seconds. >> >> I've submitted a patch with this ticket: >> http://trac.roundcube.net/ticket/1485172 > > thank you for your patch. i would like to add two things: > > 1) if rcmail::get_instance()->config->get('imap_root') gives an empty > string, the patch renders roundcube unusable. > (ok, i internally ported the patch back to 0.1.1 - maybe > rcmail::get_instance()->config->get('imap_root') takes care of that) > > 2) normally i am against the usage of globals in such a way. but this is > better than nothing :) (note: i did not check the iil sourcecode if > there is a better way to achieve that) > > cheers, > raoul > _______________________________________________ List info: http://lists.roundcube.net/dev/

2 2

Re: [RCD] Plugin-Architecture
by Florian Lagg 06 Aug '08

06 Aug '08

Hi A.L.E.C., hi all. For planning the plugin-architecture I created a todo-list here: http://www.lagg.at/temp/todo-rc-plugin You can view and edit the list after login: Login Name: roundcube Password: developer I think this step is necessary to get any needed information (such as: which actions/hooks should we implement?) Please do not delete comments of other people, if you dis-like them just add a note. I will work out an up-to-date site from time to time. Because I got some more work this week I will not be able to provide code this weekend. I think I can work on the project in two weeks again, so let's define the 19th of August as a deadline for this todo list. Bring in all your ideas until then. Read the welcome message on top of the page. Thanks -- Florian Lagg - Florian Lagg - IT-Komplettlösungen Juch 7, 6631 Lermoos tel +43 (699) 10 20 10 24 www.lagg.at - info(a)lagg.at - Xing: http://www.xing.com/go/invite/7372113.3da562 - _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

imap_root patch (significant speedup)
by Ziba Scott 06 Aug '08

06 Aug '08

Hi, We're testing roundcube in a fairly large environment (80K users, 900K mailboxes) with a cyrus imap backend. In our environment, roundcube/iloha imap's namespace discovery phase takes about 1.5 seconds on an unloaded machine. This happens on every email view. Iloha has the ability to skip the namespace discovery phase if a imap_root is configured and roundcube has a configuration option for imap_root. But the two aren't connected! By handing off the imap_root variable to iloha mail sooner rather than later we cut our time to view a message from 1.7 seconds to 0.2 seconds. I've submitted a patch with this ticket: http://trac.roundcube.net/ticket/1485172 Please let me know if there's anything I can do to help get this accepted. Thanks, Ziba -- Ziba Scott Web Application Developer Web/DB Team, Information Technology Central Services The University of Michigan _______________________________________________ List info: http://lists.roundcube.net/dev/

3 4

Updated Dutch translations
by Lazlo Westerhof 06 Aug '08

06 Aug '08

Hi all, Updated Dutch translation files are attached. Best regards, Lazlo Westerhof --- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/6C/wH4hnThr/dutchtrans_updated.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/

1 0

Re: [RCD] Plugin-Architecture
by Florian Lagg 05 Aug '08

05 Aug '08

> > Just an idea: Does it make sence to split things up? > > This 'backend-plugin' project for server side actions > > A new "frontend-plugin' project for client side things like JS, Html, > > Ajax-Client, ... > > > Server side is almost done in your patch and I think it's small part of > whole engine. The frontend side of plugins engine is most wanted. > Typical plugin needs are e.g. adding a button in tasklist, adding a tab > in Settings interface, adding a configuration option in User Preferences > (simple tasks, just for start). Of course everything needs feedback in > backend but I think frontend integration is harder to implement. If I understand you right - it does not make sence to split it - right? Fact is: I currently do not have the time to develop a frontent-plugin-architecture and not the Knowledge how RC-Frontend works (... and not the time to look at it, ...). So... What must be done to support future enhanchments in that direction? That is the question we have to think about. I do not want to re-code the whole part because it is unflexible. "I cannot do that right now" doesn't mean "I'll never do it". I just want to get things ready. * RC-Plugin-Arch. (or if you want: backend-plugin-arch. with the option to extend it to the frontend) * Funambol-Plugin These things are requested by my SaaS-customers. Afterwards we can define new milestones, team up and make the world even better ;-) Do you agree? -- Florian Lagg - Florian Lagg - IT-Komplettlösungen Juch 7, 6631 Lermoos tel +43 (699) 10 20 10 24 <http://www.lagg.at/> www.lagg.at - <mailto:info@lagg.at> info(a)lagg.at - Xing: <http://www.xing.com/go/invite/7372113.3da562> http://www.xing.com/go/invite/7372113.3da562 - _______________________________________________ List info: http://lists.roundcube.net/dev/

2 1

Sieve
by Jeroen Koekkoek 04 Aug '08

04 Aug '08

Hi Alec, and everyone else of course :-) I also created a sieve plugin, but I ported it from Avelsieve. It contains all the functionality Avelsieve has (except from the special Spam rules, they where based on other Squirrelmail plugins). I found your patch before I started working on it, but I noticed you didn't implement all the features I needed. Are you still actively developing the sieve plugin? I'm currently working on making the interface AJAX compatible. After that it should be "ready". If it isn't to much to ask, I'd like to propose that I finish my plugin and upload it somewhere so that it can become a shared effort. You see, I invested quite some time (as have you I'm sure), I would just hate it if we where both working on the exact same thing. How would you feel about that? I'm open for ideas etc. I'm hoping to hear from you. Kind regards, Jeroen Koekkoek P.S. I hope you don't find this message offending in any way, I'm just looking for the best way to implement the features I need into RoundCube. _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

backspace delete message patch
by Kris Steinhoff 04 Aug '08

04 Aug '08

I submitted a small patch which captures backspace to delete a message. http://trac.roundcube.net/ticket/1484566 This is particularly useful when using Mac laptop keyboards which don't have a forward delete key (fn-backspace sends forward delete). Are there users who will expect to have backspace take them back in their history while using RoundCube? Would it be unreasonable to break that expectation? (I think it is.) A user setting could be added to modify the behavior of this patch. -kris -- Kris Steinhoff Web Application Developer Web/DB Team, Information Technology Central Services The University of Michigan _______________________________________________ List info: http://lists.roundcube.net/dev/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev