Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com> writes:
Well, if you want IMAP UIDs also, then the tuple should include
mailbox name also!
Right, hadn't thought of that.
I am not sure what filename convention you are looking at.
No concrete plans yet. Anything that fits the POSIX portable file name
character set is fine.
server-login-folder might work, with proper escaping (maybe _2F for /,
similar to quoted-printable), but then again it might be REALLY
lengthy. Maybe an MD5 hash and a separate informative file (for human
consumption as well) that prints the hash, server, login and folder. But
MD5 might collide, so it's not perfect. Maybe a counter would work,
although then file opening becomes expensive. Open the file, read a few
lines to figure if it's the right... quite a effort.
Though, the memory saving part is right, the filenames could be
lengthy if you generate filenames based on the tuple. Also, what if
some more information is to be included in the tuple?
We'll need to rethink this then. :>
Of course, an extensible format might be good, but would we need to
extend it? If the function to generate the file name from current server
data is really a function and not copied & pasted around, then it's easy
to extend later even when we need to convert file names.
I suggest the following format for each id file (the filename will be
ignored in this format). Each id file will have a parameter section
which the relevant information about the mailbox.
server=my.mailserver.com
user=myaccountname
protocol=imap
mailbox=themailboxname # IMAP only, the mailbox is not "INBOX"
uidvalidity=themailboxid # IMAP only, if this changes clear the uid list
slowuidl=yes # POP3 only, the ids are based on slow uidl
I'd suggest we kill anything that is not "real UIDL". It's no good to
carry dead code around.
The optional parameters could include information specific to some
ids.
Free-form calls for an expensive parser. I'm not a friend of such things.
id4 1066026934 deleted=yes # this mail was deleted, but did not
# get expunged, possibly due to socket error.
"D" would do.
id5 1066026935 errors=3 # there was an error in downloading
# this mail in the last 3 polls. If
# the count reaches a limit (say 5),
# this mail will be skipped over. Such
# mails can then be downloaded by
# increasing the limit through a
# command line option.
No need.
id6 1066026936 size=1000000 # this mail of size 1 Mb was
# skipped over because of 'limit'.
# This mail will be skipped over
# unless the 'limit' option is changed
# to allow this mail.
No need.
Well, I did not mean from the header peeking point of view. TOP is an
optional command in RFC 1725. So, fetchmail should always use 'RETR n'
instead of 'TOP n some-large-number' when retrieving the header+body,
Fine with me.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95