> > 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/
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/
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/
Hi,
thanks for reviewing. I'll wait until next weekend for other ideas and
discussion.
The list so far:
> 1. Auto-calling plugin actions for build-in tasks/actions, it means we
> should add (in index.php) code for automatic calling of actions e.g.
> 'mail-compose-before', 'mail-compose-after', 'mail-sendmail-before',
> etc. and probably also 'mail-before', 'mail-after', etc.
yes - sure. btw. I like the style "mail-compose-before" (or
"user-login-after" as in my example)
It's pretty clearer than my definition.
I'll patch the existing code where I need it right now. Maybe we could team
up to implement it everywhere, or could implement it module-by-module. We
should have a list where actions should be called.
I do not have the time to do this alone.
> 2. Possibility to use own tasks/actions (I mean
> /?_task=settings&_action=myaction or /?_task=mytask)
such as a calendar-plugin ;-) lovely.
Would be great - but somewhat out of scope I think.
Shouldn't we better concentrate on the core plugin-arch and extend it later?
But we have to talk about how to implement this later.
> 3. Javascript part - for javascript functions/actions (in similar
> fasion) including point above.
again. Out of scope for my purpose.
How can we extend it later to support this?
> 4. Possibility to add UI part from plugin without skins modification.
> It's "must have", but I think, we can live without that for now.
same.
We do not have any of these options right now so let's do the core.
> 5. Actions priority - if we have few plugins for the same action which
> should be executed first?
> 6. Config option(s) for enabling/disabling plugin parts. Let's say we
> have a plugin with few features, but we need only one. Ok, we can have
> separate configuration for each plugin, but maybe something global?
> Let's say using regexp. It may be used for temporary disabling whole
> plugins without removing files from plugins/ dir. E.g.
> $rcmail_config['disabled_plugins'] = 'plugin2 plugin3::mail-compose.*
plugin3::settings.*';
Yes, agree. I thought about it but someone on the list denied the use of
configuration.
But I think this is a must-have.
$rcmail_config['disabled_plugins'] = 'plugin2 plugin3::mail-compose.*
plugin3::settings.*';
could be a problem because a plugin could possibly rely on some actions -
which could be turned off (2nd and 3rd example). What about:
$rcmail_config['enabled_plugins'] = array( 'plugin1', 'plugin2' );
If a plugin has parts which could be turned off and on it should have it's
own configuration. This is IMHO the plugin part.
> > Just to make sure. The plugin system we're talking about here doesnt
just
> > allow actions, but also small hooks everywhere throughout the
code/templates?
>
> Yes for me. I think templates engine should call plugin actions
> before/after each template object (objects, but also e.g. buttons and
> every template tag with specified name) and return content from those
> actions.
Hi, A.L.E.C., thanks for joining us in design phase ;-)
Everywhere in the code - yes. This should be a milestone in future.
Everywhere in the template - I don't know much about your templating.
How/where do we have to implement it?
Just an idea: Does it make sence to split things up?
This 'fackend-plugin' project for server side actions
A new "frontend-plugin' project for client side things like JS, Html,
Ajax-Client, ...
Both should share the ./plugins directory so that a plugin can work with
both.
As I do not have any good insight of RC-Templating this could be a bad idea
anyway. Dont know.
Waiting for futher comments ;-)
Thank you.
--
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/
Hi all,
updated Croatian translation files are attached.
Best regards,
Svebor Prstačić
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/qj/jh7F1Shg/crotrans_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/
> Message: 6
> Date: Thu, 31 Jul 2008 13:11:45 +0100
> From: Phil Weir <roundcube(a)tehinterweb.co.uk>
> Subject: Re: [RCD] Plugin-Architecture
> To: dev(a)lists.roundcube.net
> Message-ID: <619ca76367db5da740680a8de7b25c53(a)sitespider.co.uk>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
Hi,
> I have made a couple of patches for changing user password and spam
> assassin settings stuff like that. I guess you have seen Alec?s sieve
> plugin (http://alec.pl/roundcube/managesieve/).
No, I havn't.
I just looked over the patch file and these are my conclusions:
The only relevant parts to this plugin-architecture is imho in index.php.
--------------------
+ if ($RCMAIL->action=='managesieve')
+ include('program/steps/settings/managesieve.inc');
--------------------
It declares a new "action" which is called from the frontend.
Although if there should be a more generic way to extend RC for more actions
this is currently not scope of this project. Same applies to plugins on the
client side.
Tell me if I missed something. Btw: I have no Idea how sieve works. I just
know what it should do.
Don't understand me wrong. It should be in scope in future - but not now. I
want to get up & running with a minimalistic Version very quick. But I will
keep these points in mind.
> There is a guy on the forum called rosali, he has been
> working on a plugin
> arc. I told him he should send what he has got to this list
> but I don?t
> think he has.
Hm... I was refered to A.L.E.C. for the plugin project which told me he is
to busy (and the project is stalled therefore). I havn't got any Mails from
rosali.
I'll try to implement it tomorrow evening if I find some free minutes ;-)
Anyhow ... if I get some Info until then I will have a look at it. Thx.
I hope I could provide a small patch on monday for testing. But I do not
promise as I am very busy.
_______________________________________________
List info: http://lists.roundcube.net/dev/
Patrick Nagel wrote:
> Plugin or not... always debatable, I guess.
>
> Take LDAP addressbook support, for example - isn't that something that
> could
> also be provided by a plugin? It also requires configuring a backend system
> (an LDAP directory).
Absolutely - if there is a flexible framework almost everything except
the framework itself can be a plugin - with some plugins required (see
Typo3 for a great sample of this!).
But unless this Plugin system is done its hard to implement something
like this without patching the sources.... so first job: plugin
architecture!
> On a side note: funny that we're currently all using Thunderbird as our
> mail client ;)
I'm sure mainly because a desktop client is always ways better and
better performing than any Web based application can be... and on your
own systems you usually can install applications...
Mike
--
Michael Baierl
<http://mbaierl.com/blog/>
- - - - - - - - - - - - - - - - -
Viele Lieder wurden nach dramatischen Ereignissen geschrieben, man
erinnere sich an "Candle in the wind" oder "Meine Oma fährt im
Hühnerstall Motorad". (german-bash.org)
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi Everybody,
I created a sieve plugin for RoundCube. It is based on Avelsieve and is
compatible with existing Avelsieve scripts. All functionality Avelsieve has
is implemented. I would like to upload my code and let other people have a
look at it, if people are interested in it of course. Are there plans to
make sieve a part of the basic distribution? If so, how do I continue from
here?
Kind regards,
Jeroen Koekkoek
_______________________________________________
List info: http://lists.roundcube.net/dev/