-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Sat, Feb 07, 2009 at 12:13:07PM +0100, Carlos E. R. wrote:
No, por el tuyo, por poner caracteres raros en el subject :-p
Ya }:-)
Pues a ver cómo sale éste: le he cambiado el asunto y además he añadido el "símbolo raro"
No lo notarás hasta que yo haga el cambio a utf con éste.
De todas maneras, algo han cambiado los de gmail, porque esto pasa sólo recientemente.
Hace poco han actualizado la interfaz, pero a parte de eso, no han comentado nada nuevo.
Hacen cambios internos continuos.
Igual, bien. Mientras no uses caracteres por encima del 127, bien.
El Mutt dirá...
El mutt es un buen programa, no te hará esas jugarretas.
Jupe, pues ya son ganas, meterse con el mutt. ¿Y porqué no el pine/alpine?
Tanto da, uno u otro. El Mutt es más completo y soporta maildir sin necesidad de parches :-P
Y el Alpine es mucho más completo que el Pine, es más moderno y ha tenido una temporada de desarrollo muy activo. No te puedo decir si soporta maildir porque no lo uso. Espera, tengo un directorio de pruebas con maildir, voy a mirar... [...] No, no lo lee. Tiene esto: cer@nimrodel:~> ls Mail/file/entrada_maildir/ cur new tmp Pero si gmail es imap, lo que usen ellos es transparente para ti. A ver, busco "maildir" en sus listas... no, no soportan maildir y es intencional: +++ Date: Fri Jan 5 23:43:47 2007 From: Mark Crispin Subject: [Alpine-alpha] Maildir support On Sat, 6 Jan 2007, Asheesh Laroia wrote:
Joey Hess filed a bug in the Debian package (*) about Alpine lacking support for the Maildir mail storage format. Apparently the pine source package that Debian ships comes with a patch for Maildir support.
Apparently, it comes with an unsupported third-party maildir driver for the c-client library.
Do you guys (washington.edu) plan to add Maildir support to Alpine?
I (the c-client library developer) do not have any such plans. Sadly, the maildir church claims that I don't do maildir out of some evil intent. Here are the facts: I do not know how to make a maildir driver that works well, which I define as: . complete compliance with IMAP's specifications . complete compliance with DSB's specifications . satisfactory performance I know how to do two of these, but not all three simultaneously. I refuse to have my name associated with IMAP non-compliance. DSB would flame me to a crisp if I don't comply with his maildir specifications. That leaves lousy performance, and I would be flamed for "deliberately making it because [I] dislike maildir." It's a no-win situation for me.
From what I have seen of the third-party maildir drivers, they cut corners on all three. Some also have a negative impact on non-maildir usage.
I've fielded numerous Pine/c-client bug reports which turned out to be caused by these maildir drivers. When it turns out that the user does not use maildir, I recommend that s/he replace whatever distribution with an unmodified UW distribution (which of course has the effect of deleting any other third-party customizations). Similar corner-cutting is done by the IMAP servers that support maildir. For example, Courier actually implements something that it calls maildir++ and a heresy of IMAP that it calls SMAP instead of true maildir and IMAP. The difficulty is that IMAP and maildir have some seriously conflicting requirements. Neither one considered the other when it was designed, and it shows.
If not, has anyone in the community considered writing such a patch for Alpine?
I'm sure that the third-parties which provide maildir drivers for older versions of the c-client library have (or will soon have) updated versions that fit in the imap-2006 version that is used by Alpine. Please be assured that if I had a brainstorm and suddenly realized how to write a maildir driver that works well (as defined above), I would do so. I haven't had such a brainstorm, and apparently nobody else has either. - -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ++- (Mark es uno de los desarrolladores principales de Pine/Alpine, y Asheesh creo que debe ser alguien en Debian, posiblemente el empaquetador de Alpine) Lo que si soporta son carpetas "mix", que es otro formato de carpetas de correo bastante optimizado. Me acabo de enterar, por cierto. Mark Crispin - Fri Jan 19 14:37:38 2007: +++ Alpine, and Pine before it, has supported multiple mailbox formats since inception. mix is simply the latest in a long history. mix was developed in 2006 to replace mbx, which was the 1995 solution for the performance problems caused by traditional UNIX (a.k.a. mbox) format. The email world today is very different one from 1995; and what was a good solution to mail in 1995 no longer is so good today. mbox, in turn, was a solution for the 1970s and 1980s. People still use it for a number of reasons, but it is quite obsolete today. ... Both mbx and mix support concurrent access. Furthermore, message and mailbox metadata is stored outside the message texts; no more Status:, X-Status:, X-UID:, etc. lines, and no more DO NOT DELETE message. The main user-visible addition in mix is that it allows "dual-use" mailboxes; that is, mailboxes which contain both messages and other mailboxes. Although this may seem bizarre to Pine users, it's something that users of Outlook, Thunderbird, etc. have been demanding for a long time. mix has a message index, which causes opens of large mailboxes to be MUCH faster than mbx (or mbox); strong data isolation (which reduces the change of mailbox corruption); less data re-writing than mbox; a cache of sort data (which makes first sorts of large mailboxes MUCH faster); and is extensible for recently-defined IMAP extensions which are not yet implemented but will become important. Unlike mbox and mbx, a mix mailbox is a directory. However, unlike mh, netnews, and maildir formats, mix does not require that each message be in a file by itself. Instead, it attempts to collect multiple messages in 1MB (this value is configurable in the code) data files, starting a new data file when the current one fills. This makes backups work much faster, avoids godzilla mailboxes creating godzilla files, and also avoids the excessive inode consumption that happens with mh/netnews/maildir type formats. The godzilla file problem needs some discussion. The current code limits the maximum mbox and mbx mailbox size to 2GB, at which point it craps out. mix does not have this limitation, although there is a limitation, inherited from IMAP, that an individual message can not be more than 4GB (hopefully this limit is good enough for a few more years to come...). There is one negative about both mbx and mix; neither format is supported over NFS and doing so is likely to cause corruption when concurrent access is attempted. NFS is not a suitable remote access mechanism for mailboxes; use IMAP instead. ++- Tira por tierra lo de que mail dir soporte acceso concurrente, es falso: +++
If I remember correctly, it was a big advantage of maildir and similar formats where each message is stored in a single file, that these kind of operations required only a minimum of I/O as in contrary to mbox and IIRC mbx formats, not the whole file had to be rewritten.
There is no synchronization in maildir. This is one of the problems with that format; a message just suddenly vanishes even while another session is still accessing it.
So, how does "mix" format deal with that situation?
mix has modification sequences and locking which permit multiple access (including shared expunge) without pulling the rug out from under other sessions that are still accessing those messages. There are well-defined synchronization points in IMAP in which a session learns about an expunge, and mix guarantees that data from an expunged message in another session remains accessable until those synchronization points.
In the doc file I read something of "burping", but I am not sure I understand fully what is meant by this term here. Are you moving up fragments of other already existing messages from the end of the file to a place that has just been "freed" somehow?
When a message is expunged and there is no concurrent access, the space occupied by that message can be reclaimed. If an expunged message is the last one in the data file, then the file is truncated. Otherwise, the remaining messages in the file are moved on top of the expunge messages and then the file is truncated.
What if the size of the no longer needed area does not fit exactly?
This is not relevant to how it works.
And what happens if the message to be expunged is more than 1 MB and thus split up into multiple files of 1 MB size (the value you told us which is configurable in code) with possibly other message in front of the first or behind the last part?
A message is not split into multiple files. A message larger than 1MB (or whatever is the configured size) is generally written into a file of its own. The exception is with multiple copy/append; all messages in the multiple copy/append are written to a single file regardless of size.
How does the performance compare to e.g. maildir regarding these kinds of operations?
I have no interest in comparing to maildir, since maildir does not correctly implement IMAP semantics. Since maildir can not do concurrent access properly, the advocates of that class of storage insist that IMAP be relaxed to allow what maildir does. Hence you have RFC 2180 sections 4.1.2, 4.1.3, and 4.1.4 as alternatives to 4.1.1 which is the only client friendly behavior. It is very easy to make things faster by saying "we don't need this" and "we don't need that" when "this" and "that" get in the way. For example, a filesystem can be sped up enormously if you don't care about it being robust and consistent in a power failure (the secret of fast Linux filesystems). Similarly, NFS would be severely slowed down if it had to fully implement UNIX filesystem semantics (ever notice that O_EXCL doesn't really work on NFS?). mix format generally does far fewer writes than mbx or mbox format. It never writes the index file unless a message is added or removed; flag changes take place in the status file. Concurrent expunge affects only the index and status files; only single-access expunge will rewrite data files. The data files are much smaller than the flat file formats, leading to much smaller rewrites. Of course, if a data file ends up with no messages, it is deleted rather than rewritten. In the specific case of a 2GB mailbox where the first message is expunged, mbox and mbx formats have to rewrite the entire 2GB mailbox. mix only rewrites the index file, status file, and the data file that holds that message. That may be "slower" than maildir's deletion of a file, but in terms of real time there is no user-visible difference; and in mix you get proper concurrent process synchronization with no confusion about "where did that message just go". - -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ++- Vamos, que lo de Maildir... este hombre está totalmente en contra, y sabe lo que dice. Claro, que puedes decir que es como Stallman :-p De todas maneras, mix no estaba terminado cuando escribió lo de arriba. Ah, el archivo de lo de arriba dicen que está aquí - no lo he probado: +++ RTFArchive (you have to get your password sent to you first if you don't know it)... see the thread starting here: https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... esp: https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... and the thread starting here: https://mailman1.u.washington.edu/mailman/private/alpine-alpha/2007-January/... ++- De todos modos, Eduardo Chappa hizo un parche para usar maildir; pero ese parche (todos los suyos) los tengo aplicados y no puedo acceder. Tampoco se si ese maildir está correcto. (Son los mismos parches que aplica suse).
Pero el problema que tengo es un problema de concepto, con el Gmail (etiquetas y filtros).
Lo único que me faltaría en el Mutt es poder "archivar" los correos que están en la bandeja de entrada para que se almacenen en su carpeta (label) de la lista, pero no doy con la forma de hacerlo.
Los manuales que encuentro no dicen ni cómo, ni si es posible llevarlo a cabo y la mayoría de ellos utilizan una configuración local, es decir, que almacenan los correos en su equipo, no en el servidor. Y no voy a almacenar los 30.000 hilos con 80.000 mensajes en mi equipo, ya tengo bastantes con los del KMail >:-)
Ah, ya, quieres aplicar filtros que recojan el correo de la carpeta "inbox" y los muevan a otras carpetas remotas via imap, ¿no? Revisa la ayuda de gmail sobre el acceso imap y los filtros, hablan de esto precisamente. Es mejor, creo, dejar que gmail (servidor) haga ese filtrado y movimiento internamente. (Aclaración para los demás: los labels en el webmail son carpetas en imap, para gmail)
Si no encuentro una forma de archivar los mensajes en remoto, tendré que volver al webmail :-(
Leete la ayuda de gmail antes, está previsto.
Puede que se deje cambiar. En el pine se puede cambiar, al joe, por ejemplo.
Sí, eso claro que se puede cambiar. Puedes usar el editor que quieras.
El vim no está mal, sólo es cuestión de memorizar unas cuantas "teclitas" :-)
¿Unas cuantas? >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmNlz4ACgkQtTMYHG2NR9XUcwCeLOmTBMXp2+QzV5RUxCYV0Hv0 UEsAoIYAj1pvC1jEXaA1xcj81nyiu5ma =ZzAk -----END PGP SIGNATURE-----