Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For me, an additional concern is being tied to this client after using it. Every offline mail client has its own storage formats (mbox, maildir, SQLite, another database or a mix of these), and so moving across clients is not an easy exercise unless the clients support multiple formats for import. I would also like to see how the client behaves when one single mailbox is more than 20GB in size, with at least one of the folders being around 3-4GB by itself. Claims that searches happen in milliseconds need to state the size of the mailbox and the folders (and also include enough variability in the content for the index to be large enough).

I certainly like the idea of new email clients, especially those that integrate with Exchange calender (a weak point for Thunderbird even with extensions). But in my view, building a fast, robust and feature rich email client would take about an effort of 10-30 person years or even more, depending on the feature set. This one seems to stand at a mere two person years, and so my expectations would be quite low (though it's still in beta and states upfront some of the important features it's missing).

P.S.: I'm a supporter of Thunderbird and donate money to the project. https://donate.mozilla.org/en-US/thunderbird/



I think the largest inbox ever tried in Ivelope so far is around 10GB and from what I heard from that user, there were no major problems - but I haven't made any measurements. A few people have requested mbox import and it is on the todolist.


Since you responded elsewhere that your client stores mails in a proprietary format, one very important product goal should be an export mechanism that can export to one, if not more, of the common formats (mbox, maildir, etc.). After all, if you’re confident on your client’s features as the USP to get customers, you should also easily allow those who want to move out to do so. I personally wouldn’t try our client for serious use otherwise.


Of course, I haven't put my focus on this yet, but it is on the todo list.


> Claims that searches happen in milliseconds need to state the size of the mailbox

I'd honestly outsource the indexing and searching to something like mairix which is designed purely for this purpose.

(On my 4.5GB Maildir, 57 folders, 111k emails, mairix takes 205s to index from scratch. Incremental updates are <5s. Worst search I've yet done took 0.5s to return 13k hits for 'bank'.)


Or "notmuch" which has integration with Mutt and similar mailboxes, and it has GMail-like tagging and boolean searches.


Interesting, thanks! Trying that now. Took twice as long (13m) to index my folders (and ignoring a whole bunch of fake-mbox files that seem to be coming from my gmail-to-local forwarding) but the searching is about the same kind of speed as `mairix`.


I had a very quick look at the mairix repo on GitHub, and I'm not sure what to make of at least one pull request (about large mailboxes) that has no comments on it for a few years. Though it's an old project, I just wanted to confirm that it's still good enough to use without too many issues and also check if you're using the main one [1] or any of the other forks. [2]

[1]: https://github.com/rc0/mairix/

[2]: https://github.com/rc0/mairix/network


Couldn't tell you offhand, sorry - I'm using the Arch Linux community package which doesn't explicitly state where it's coming from. Currently v0.24-1 if that helps figure it out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: