Throwing it together

While I was not searching for a new project, I have been throwing TMut together. After six quick sessions of working on it, I made TMut:

  • Support multiple accounts simultaneously
  • Open and display text/plain and text/html E-mail
  • Open and display IMAP folders
  • Open and display the INBOX of a POP account
  • Delete IMAP and Maildir folders
  • Create IMAP and Maildir folders
  • Move IMAP and Maildir folders
  • Copy IMAP, POP and Maildir folders
  • Rename IMAP and Maildir folders
  • Delete messages from IMAP folders
  • Delete messages from POP folders
  • Move messages from one folder to another
  • Put the connection in IDLE on IMAP and receive notifications
  • Create new messages
  • Create a reply of a message
  • Create a forward of a message, as attachment
  • Have accurate progress information

Not unimportant but because Tinymail comes with this support I also made TMut:

  • Do CONDSTORE on IMAP
  • Do QRESYNC on IMAP
  • Do BINARY on IMAP
  • Do IDLE on IMAP
  • Do various SSL and TLS encrypting
  • Do various authentication methods

I’m planning to fine tune all this a little bit, then do a GPEPhone port of it. This will include overriding some of the virtual methods that are right now creating a more or less standard user interface for a GNOME desktop.

I also have to make some sort of optional account editor. Optional because some device vendors have the account editing done by a web page and then uploaded to the device via an SMS (this is not uncommon on for example Nokia phones). I just remember I still have to make a little bit UI for adding and removing attachments from a new message too. When forwarding the forwared message is right now added as an attachment already.

Once all that is finished I of course have to prepare a video demo of running code. I guess the VMWare image will help me a lot with that. After that demo, I will most likely do a release of TMut. Perhaps at the same time release a first Tinymail version too? I’m not sure of that yet. Perhaps I will do a few more pre-releases in stead. It has to be perfect.

I think TMut is ready for contributors now. If you want to join and hack together your favourite E-mail client feature, just get on the Tinymail mailing list and post me your great patches. I also have to document the code of TMut a bit more. And make TMut’s wiki page a bit better too.

The joy of starting yet another cute little project starts …

8 thoughts on “Throwing it together”

  1. Hello, just a quick question about TMut and TinyMail in general. Is it possible to load a big folder (thousands of messages) without loading all message header at once? Is it possible to load only the messages currently viewed on the message list, and minimise that way both bandwidth and memory consumption (pine is the only client I know that works that way)?

  2. The memory consumption of 50.000 such headers is around 20Mb. That’s because I use mmap() for these headers. You don’t need to worry too much about that memory consumption.

    The way IMAP works does not really make this easy. What items does the user want? Just the latest ones or sorted on a field? With IMAP you can’t easily ask for a sequence index in a sorted way. Although there are proposals to change the protocol to have this kind of functionality.

    The problem is that the IMAP server is free to define its own sort order and that as E-Mail client you can’t know for sure that if you downloaded say, the last ten of the sequence index, that you actually have the last ten that got received. Maybe the IMAP server decided not to store those real last ten E-mails at the ending of the sequence index? You can’t know this in the client (unless you assume know-how of the specific IMAP server’s implementation, which you should never do as client).

    Take a look at CONTEXT and the other “VFOLDER on server” protocol proposals. Dave Cridland is the guy doing most work on this.

  3. Also note that Tinymail downloads really a limited amount of data per item at first. Only when opening the message will Tinymail fetch the full message. If not opened, on IMAP, you’ll receive just the headers needed to display the summary of the folder.

    On POP Tinymail uses TOP for this. These are all the headers of the E-mail (but only the headers, not the entire E-mail).

    I of course recommend IMAP for mobile users. Also because on POP you need to request each TOP separately. Which means a roundtrip for each and every message. Whereas with IMAP you ask for one query, and it starts sending you the results. That’s far less roundtrips of course. On high latency networks like GPRS this makes a real and significant difference on network performance.

  4. Hey philip, thanks for your reply. Even 20MB could be an issue for embedded devices, and I already have a folder with 200k messages. Moreover when transfering data through your mobile phone which charges per kilobyte, you don’t want all folder headers to be transfered.

    It is already doable in pine so I suppose tinymail can do it too. Most current IMAP servers support server-side sorting and threading. If you want I can get some debugging data from pine while accessing a folder, sorting it and threading it, and email it to you. That way we’ll find out what commands it actually sends…

  5. Finally. An However about all this …

    What you can do if you are sure that the client will always be used while online, is to get just the headers you are viewing in the view component at the time of the row becoming visible (as the scrollbar gets used).

    Dave Cridland’s Polymer and Telomer work this way. I think Mulberry does something similar. Although this is definitely doable, it’s not the scope of Tinymail as Tinymail tries to support consulting the data that you have locally already in case you are offline too (showing an overview of the folder when you are offline).

    Telomer, Polymer and Mulberry require that you are online at all times. Although I think Dave is planning to make it possible to use pieces of his client while you are offline too. By caching what got received already, and displaying “…” labels in case you never once retrieved the row being showed.

    This is of course an interesting concept to experiment with, yes.

  6. jimis: you have SORT and CONTEXT=SORT. But these capabilities are not in IMAP’s RFC (a lot of IMAP servers implement it, though). Making this a requirement would make it impossible for some perfectly fine IMAP servers to be used by the client.

    Courier also gets THREAD wrong, so letting the server do threading might get tricky.

  7. FWIW, CONTEXT=SORT is only implemented in one server, in an unreleased version. SORT is implemented in all major servers.

    Now… Mulberry does work offline, as far as I know. It concentrates on fetching the data you need “right now” when you’re using it, but also fetches other data for offline usage when you’re not doing anything else.

    You can – sort of – get the best of both worlds. The problem is that if you’re on a particularly bad, or expensive, connection, the most efficient way to do things is not to pre-fetch data at all, and just grab data on demand. Otherwise you risk choking the line, as well as incurring cost for transferring data that the user doesn’t actually want.

    Polymer can’t tell what sort of connection you’re on, so I erred on the side of caution – especially with my mobile tariff – and so it doesn’t prefetch much that you’re not directly looking at.

    That said, it’s pretty close to working offline with whatever it has – it acts as if it’s online, but with infinitely high latency. This doesn’t work – quite – yet, but there’s not actually that much left to do.

    I still maintain that the most interesting aspect of Polymer isn’t all this scalability for huge mailboxes on pathetic bandwidth stuff – that’s all done purely to annoy Philip, after all – but the ACAP support, which allows you to use Polymer to configure Telomer, and, in principle, any other ACAP-supporting MUA.

    (So when’s that ACAP support coming to TinyMail, then, eh?)

  8. Heh – to annoy Philip, damn you!! – :-).

    Support for ACAP is on my priority list. And not very difficult to implement (I think).

    Take a look at the libtinymail-acap subdirectory in the repository to see what I prepared already.

Comments are closed.