[Mail.manager] Benvenuti!

[Niko!]

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

purtroppo sì! quando mi chiamano da lettere chiudo la porta della stanza
sigh :(

> > 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.)

infatti, ringrazio per la segnalazione Andrea, inizialmente avevamo optato
per il perl perchè non sapevo dell'esistenza di tale libreria

> 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''

magari la libreria potrebbe essere utile per creare gli script, verificarne
la correttezza, gestirne il salvataggio delle pseudoregole etc.
poi l'applicativo web si baserebbe su tale libreria

> > 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

eh già, chissà se IETF ha proposto/accettato qualcosa di alternativo!

> > 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)

il server su cui era ospitato diciamo che è "indisponibile" per gravi
problemi hw al controller :(
ma dovrei avere un dump da qualche parte datemi un pò di tempo per trovarlo!

> > 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".

cerchiamo di trovare la cosa + intuitiva possibile, magari sarebbe utile
sondare il terreno direttamente con gli utenti

>
> 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...)

umh... è semplice sicuramente, ma io voglio esagerare...

piuttosto se il campo "from" contiente pippo a unina.it allora sposta nella
cartella posta indesiderata

preferisco

elenco dei mittenti da cui non si desidera ricevere posta!
e così via...

> > 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...)

si qualcosa del genere... mi sono espresso male con il termine pop-up

> > 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.

la cosa migliore è fare un js che migliori l'interfaccia ma che non diventi
indispensabile!
in pratica su browser senza js io non vedo l'help, non mi esce la
finistrella che mi dice "attenzione hai dimenticato di inserire un campo" ma
riesco ancora a fare tutto (con i dovuti controlli lato server)!

> 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...

Ecco cosa intendevo poco sopra!

>Ciao,
>   Guido

Ciao
    Niko