[ingo] RFC: how to support custom sieve filters

[Ivan Sergio Borgonovo]

On 08/29/2014 07:36 PM, Jan Schneider wrote:

>>> This is not a bug, but the consequence of Ingo not being a Sieve
>>> frontend, but an abstract filter frontend for different filter backends.
>>> It *must* store rules and states locally, and it won't work with any
>>> external provided scripts or changes.

>> Let's say it is a very scary feature then ;)

> Why? It's non-destructive.

It is very annoying at least if the only thing you have is web access.
And many times people are using a webmail clients because they just have
web connectivity or they just have a browser as a tool.

>> I'm aware that supporting many filter backends with a consistent
>> frontend isn't an easy task.
>> I'm wondering what is the use case.

> Not having to develop different frontends for different scripting
> backends. And being able to switch between filter backends without
> losing rules.

I perfectly understand this as a developer, I understand it less as a
user... but I may not be a representative user.
Do people really switch more than one time in a single job place their
filter backend?

>> What's missing is the ability to manage (activate/deactivate) more than
>> one script. This has no relationship with what ingo store in the DB and
>> doesn't require ingo parse back what it finds in an alien script.

>> If you just have web access and you unfortunately touch ANYTHING in ingo
>> filter interface you may end up deactivating a perfectly working filter
>> without any chance to activate it back.

> I'd say it's not too much asked from a user to either use Ingo or create
> and manage their sieve scripts manually.

I still have to think about it but I think it may be trivial to mix. You
write an ingo script, don't activate it and you include it in a
handwritten script. If you're writing your handwritten script I think
you'd know how include works.
I think the interface for whitelisting/blacklisting would be comfortable
even for people that write their own rules.

> You can already use sieve includes in you manually created scripts and
> include the script generated by Ingo.

OK, so it seems that the only missing piece is... managing sieve scripts
otherwise there is no clear way how to switch from ingo filter to your
handwritten one but later you said that ingo was not meant to be a
managesieve interface.

>> So let be more concrete and let me know what's against the project
>> policy.
>>
>> I'll turn the "Script" link into a "Scripts" link.
>> There you'll see a list of scripts you could View, Activate and Edit.
>> If you edit the ingo script (accordingly to what is set in the
>> backends.local.php) you'll be redirected to the GUI. If you Edit another
>> filter you get redirected to a TEXTAREA.

> Yes, this is how it should work if it is ever going to be implemented.

That's why I'm writing here. I'm asking if this is the way you'll accept
it to see if it is worth to dig further in the existing code and find
some time to try to implement it.

>> I can see in how many ways this is going to break the "common interface
>> for all backends". Among all this would require turning on explicitly
>> even ingo generated filter.

> No, why, the default use case would still be the same. Beside that, you
> can already configure now if script changes should automatically or
> manually be uploaded.

I did miss this. Where? Is it a global/administrative setting or a per
user setting?

>> But this is the less intrusive way I could think of. If ingo is not
>> going to support the idea of "managing" more than one script you'll have
>> to introduce a much harder to understand and manage concept to switch
>> from a hand written script to an ingo generated one: overwrite my
>> handwritten script.
>>
>> Still I think that the chance of deactivating a perfectly running sieve
>> script without any way to activate it back is pretty scary and have to
>> be solved some way. I don't think this can be solved without introducing
>> at least for the sieve filter frontend the concept of multiple scripts.

> Don't let users use Ingo, if they already use some other tool to manage
> their scripts.

And the only obstacle is having something from where you can select
which script you want to activate?
If adding this feature is OK it seems that everything else could be
built without any substantial change in other backends UI.

BTW there is no such a tool that I'm aware of that is not glued together
with the webmail it comes from. That means if you chose to use horde you
won't be able to manage your sieve script through HTTP(S). If you use
squirrelmail or roundcube you will.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it