[Mail.manager] Benvenuti!

[Guido De Rosa]

On Wed, 26 May 2004 09:29:11 +0200
"Niko!" <niko a unina.it> wrote:

> Come fonte di ispirazione va benissimo, ma dobbiamo "purtroppo" considerare
> il livello di competenza degli utenti *@unina.it" che vi assicuro (il mio
> telefono insegna) che non sanno distinguere un indirizzo e-mail da una
> username!

Dunque, pur essendo più amichevole di websieve.pl, 
è ancora *troppo difficile*... Uhm...

> inoltre, il tool dovrebbe essere "esterno" e non integrato in
> un'applicazione, in tal modo la sua applicazione potrebbe avvenire su scala

Beh, allora si potrebbe lavorare a uno script php "standalone", 
scrivendo molto codice da zero ma "scopiazzando" qualcosa da avelsieve:
un'idea sarebbe trasformarlo in una libreria... infatti, la libreria
sieve-php (http://sieve-php.sourceforge.net/) su cui avelsieve già 
si basa gestisce solo il trasferimento via rete dello script, senza sapere 
nulla del linguaggio sieve (semantica, sintassi, etc.)

La libreria che vorrei trarne sarebbe dunque un estensione di sieve-php,
poi solo l'esperienza dirà se vale la pena di ravanare nel codice
preesistente o è più conveniente reimplementare tutto da capo...

La speranza è, ovviamente, che alla fine di tutto 'sto lavoraccio
si possa realizzare il nostro tool in modo più pulito e ``scalabile''

> maggiore, considerate che il SIEVE è praticamente uno standard, e tutti i
> backend di posta elettronica in futuro lo supporteranno.

Piccola nota: se è vero che per il linguaggio SIEVE esiste una RFC
purtroppo non si può dire altrettanto del protocollo di trasferimento
managesieve: infatti, se non interpreto male, uno standard è 
stato proposto:

http://www.cyrusoft.com/sieve/drafts/managesieve-04.txt

però non è stato accettato dall'IETF:

http://www.ietf.org/internet-drafts/draft-martin-managesieve-05.txt


***
Rispondo anche all'altra mail di Niko:

> In effetti il primo prototipo esistente del tool è molto semplice, in
> pratica permette all'utente di creare:

Mi daresti l'URL in cui provarlo? E il sorgente? Forse me l'hai detto
quando ci siamo visti di persona, ma non mi ricordo più... Poi, se la 
cosa prende piede si potrebbe tirar su un albero CVS (tempo e buona
volontà permettendo)

> 1) black_list (elenco di indirizzi, subject, etc le cui mail vengono
> automaticamente catalogate come indesiderate)
> 2) white_list ("" vengono automaticamente considerate "safe", anche se
> spamassassin le castiga)
> 3) forward_list ("" "" inoltrate verso indirizzi esterni)
> 4) discard_list ("" si capisce)
> 5) un vacation message
> 6) la scelta di un profilo antispam (es. cancellazione automatica dello
> spam, risposta automatica allo spam, reinoltro in sottocartella etc.)

Oddio, non è che "forward list", "vacation list" e simili siano 
concetti più amichevoli di "Se l'Oggetto contiene questo, allora 
salva nella cartella..."

Ho l'impressione che sia più facile parlare di "regole" che di
"liste", così anche la precedenza di una regola su un'altra 
appare evidente "visivamente".

Non a caso, un provider commerciale (email.it) che certo ci tiene
ad essere user-friendly, ha adottato questa impostazione

http://studenti.unina.it/~gcderosa/examples/preferences_filters.php.html

(è un po' bruttino a vedersi, ma mancano immagini, fogli di stile, 
e gran parte del codice, che ho eliminato per non incorrere in 
violazioni di copyright, l'importante era rendere l'idea...)


> L'utente deve dunque avere un'interfaccia semplicissima e molto molto
> intuitiva! (un pò di js con popup help non sarebbe male)

E` una buona idea. Anche qualcosa come <DIV CLASS="CTooltip" ID="...">
può essere utile: fa apparire una piccola textbox al passaggio del mouse,
come accade in tante applicazioni desktop e, se si vuole, è meno
invasivo del pop-up (beh, se sia migliore o peggiore è oggetto di 
discussione...)

***
Andrea D'Amore ha scritto

> Aaaaaaaaahh!!! Ti prego !
> 
> Io sono uno di quelli che non riesce a prenotare gli esami da 
> esis.ceda.unina.it perche' non uso IE...
> 
> Ma le form html che hanno di male?

Hanno di male (almeno questa è la mia interpretazione)
che i dati di un form sono processati lato server 
(GCI, php o altro) e quindi l'uso andrebbe limitato 
allo stretto necessario: tutto il resto (come le 
richieste di help) andrebbe elaborato il più
possibile dal client, quindi meglio javascript
o anche semplici link a paginette html statiche.

Peraltro, qualcosa come 
<a href="help/topic_id.html" onMouseClick="popupFunc();">
  <img src="icons/punto_interrogativo.png" alt=" ( Aiuto ) ">
</a>
salverebbe capra e cavoli, consentendo l'accesso persino
a un browser testuale che non supporta javascript...


-- 
Ciao,
  Guido