[RCD] Filters: Very new UI

emi at algorismia.com emi at algorismia.com
Fri Jan 11 20:46:08 CET 2008


Hi Pim!
As you can seein previous mails on this list, RC internal filters are not
very much popular ;D, but I've coded on the first filters version, easily
upgradable to the new ones. It's a list decision. If this a possibility
and not the only solution (as you sat) may be is a better way accepted by
everyone.

Regards,
emi

El Vie, 11 de Enero de 2008, 20:23, Pim Vullers escribió:
> I really like the idea of filters in Roundcube. I love them in
> Thunderbird.
>
>
> But what about 'native' filter support for RC? For example make it
> possible to choose the server filtering mechanism, but also make it
> possible that RC itself filters the messages. As for example I use RC for
> mailaccess to my IMAP account at my hosting provider. However I do not
> control the server such that I don't have access to the server
> configuration and so on, which means that my client applications will have
> to do the filtering.
>
> Have there been any thoughts about things like this?
>
>
> Kind regards,
> Pim
>
>
> chris# wrote:
>> On Thu, 10 Jan 2008 19:19:42 +0100, "emi delg" <emidaruma at gmail.com>
>> wrote:
>>
>>> Hi Javier and Chris!!
>>> Javier:
>>> 1.- Sorry, the translator script is a shell script written in PHP (to
>>> take the db info and rest). It's easy to make a UI (frontend) for
>>> this. 2.- What is RPC?
>>>
>>
>> Remote Procedure Call
>> Often used in an XMLRPC form as well.
>>
>>
>>> 3.- That's a good idea to make them compatible, but structured
>>> filtering is not just ordered filtering. I mean: we should work on
>>> improving the old UI to be able to create what the new one can: reply,
>>> forward, delete, copy and if/else. Copy and if/else are the most
>>> complicated features to develop on the text UI, because these have 2
>>> possibilities after them.
>>>
>>> Chris:
>>> 1.- RoundCube have to know which is the end filtering system because
>>> probably not all of them have all the features (actual and future), so
>>> you (as mail admin) will need to block some of the features. For sure
>>> this is a config issue.
>>
>> I can see easily where RC could parse and ini file to obtain the
>> /current/ feature
>> set for all supported filters. That would make very easy to to produce a
>> form with checkboxes to enable/disable grouped and or individual
>> options/features. The rest, of course would be up to the admin -
>> providing user-based, or global options.
>>
>>> ¿Are we able to make an admin entrance to enable RC administration
>>> via web?
>>
>> Yes, quite easily.
>> if !isset admin, read-most else readall
>>
>>> It would be great!!
>>>
>>
>> Indeed.
>>
>>
>>> 2.- Every mail system has it's own and very different working method.
>>> You
>>> can have, for example, a DB based users auth or just a Linux users
>>> auth, IMAP on a server and RC on another one and LDAP auth on a third
>>> one, etc You
>>> can configure each of the filtering system nearly as you want, so it's
>>>  difficult for RC to do all the work. What I mean is that mail
>>> configuration is nearly chaotic to improve all the possibilities. Due
>>> to this issue, we can think on an intermediate solution, which, for
>>> example, lets the admin to create the scripts that will be executed by
>>> RC automatically to save the
>>> filters on the right way.
>>
>> See my comment above.
>>
>>
>>> 2008/1/10, J. Javier Maestro <roundcube-devel at nosys.es>:
>>>
>>>> On Jan Thu 10 2008 18:19, emi delg wrote:
>>>>
>>>>> Hi Javier!!
>>>>> The simpler filters UI is testable at https://mail.cio.cat with
>>>>> same
>>>> user
>>>>> and passwd.
>>>> Cool, I'll have a look at it as soon as I have some free time.
>>>>
>>>>
>>>>> May be we can add both UIs and let the user/admin decide whether
>>>>> to
>>> use
>>>> one
>>>>> or the other.
>>>> I think the best model would be something like:
>>>>
>>>>
>>>> - Let the basic, text-based UI form be the default
>>>>
>>>>
>>>> - This should use the usual .inc functions in program/steps,
>>>> broken in (duh!) simple steps such as save_filter.inc,
>>>> translate_filter.inc, etc.
>>>>
>>>> - Finally, the graphic UI should construct the same textual info
>>>> from the text-UI but using the graphic UI, and then pass it to the
>>>> same step .inc files from the textual UI.
>>>>
>>>> - The .inc in steps/ should be doing the translation in PHP...
>>>> doing it in a bash script is OK, but I think integrating it into PHP
>>>> would be better). Then, they should send this maildrop, procmail,
>>>> whatever filter to a central server through RPC, to
>>> incorporate
>>>> it in the user mail-flow, etc.
>>>>
>>>>
>>>> --
>>>> J. Javier Maestro  <jjmaestro at nosys.es>
>>>> Socio Consultor   -    Nosys AJjV S.L.
>>>>
>>>>
>> /////////////////////////////////////////////////////
>> Service provided by hitOmeter.NET internet messaging!
>> .
>>
>>
>>
>> _______________________________________________
>> List info: http://lists.roundcube.net/dev/
>>
>
>
> --
> Pim Vullers
> Heerstraat 29 / 5953 GE Reuver
> pim at vullersmail.nl
>
>
>
>
> --- 8< --- detachments --- 8< ---
> The following attachments have been detached and are available for
> viewing. http://detached.gigo.com/rc/D5/7saVCTo8/signature.asc
> Only click these links if you trust the sender, as well as this message.
> --- 8< --- detachments --- 8< ---
>
>
> _______________________________________________
> List info: http://lists.roundcube.net/dev/
>
>


_______________________________________________
List info: http://lists.roundcube.net/dev/



More information about the Dev mailing list