Hacker News new | past | comments | ask | show | jobs | submit login

IMAP actually does have labels. They are called flags. Servers tend to not implement them well at all (sometimes allowing only a handful to exist, and almost never keeping an index for that metadata, meaning that searches by flag are either slow or often not even allowed :/), but that is not the fault of IMAP.



Apparently, most sane open source IMAP servers support PERMANENTFLAGS \ * which as I understand it means user-defined flags?:

http://serverfault.com/questions/115769/which-imap-flags-are...

I'm not entirely sure what's "happened with email in 10 years"? Search-defined virtual folders?


And, FWIW, search defined virtual folder is a client concept and would be trivially implemented over IMAP's incredibly powerful (and I believe I remember being even extensible) search commands, if only IMAP servers tended to provide the right kinds of index to make such queries fast. (I know this, as I was working on a highly scalable and very efficient IMAP server a few years ago that I had to force myself to stop working on as it was too much of a distraction from the things in life that are actually capable of putting food on the table.)

Mark Crispin was actually pretty-damned prescient when it came to IMAP: he believed that client operations should be offloaded to a server that would have much more disk space and CPU than the client, which is exactly the model everyone reaches for today, and thereby designed a thin client protocol that had asynchronous updates baked into its core. A few years ago, he passed away: here is what I wrote at the time about his mission for IMAP and history on the project.

https://news.ycombinator.com/item?id=4826113

Really, the only thing in IMAP to actively dislike is how the thin client view requires the server to have a "dense" (here I mean the mathematics term, not from the technical spec) numbering of messages the client is modeling in its view (this is the reason opening a large mailbox via Zimbra takes forever, and why many IMAP servers have dumb global locks), but I have come up with some techniques that should allow me to handle that with minimal overhead. Otherwise, with some of the modern extensions in place (QRESYNC, for example), IMAP is pretty damned awesome.


IIRC, IMAP flags/keywords were limited compared to folders (and a message can't belong to multiple folders). But maybe I got a wrong idea when I read the RFCs...


I would need a more concrete complaint to tell you why you are probably wrong here. The only thing I know of that tends to cause people to balk at flags is the frustrating idea that the name of the flag for some reason has to be the same as the name shown to the user, so the inability to rename flags or even use special characters causes people to give up on them... but you should treat them as opaque database tokens, not user-visible metadata, and map them to names. There was then an extension being worked on to store high-level names in the IMAP metadata store, but I don't know if it got completed (I havent paid much attention since Mark Crispin passed away: I felt like he was one of the few people keeping IMAP from losing its way, so I am highly concerned that I'm going to read through the mailing list and find people frantically pushing through all the stuff he had vetoed). But like, adding your own "documented but non-standard" blob to IMAP's metadata would still be worlds better than throwing away the entire protocol and starting over again from scratch :/. Honestly, I think the core issue with people working on IMAP is that people these days have very little data structure and algorithm training, particularly when it comes to implementations of parsers, and so when they stare into IMAP they miss the forest for the trees and barely scratch the surface of what it can accomplish before giving up and screaming for their JSON and HTTP. (That, and the dense numbering for message views, which is a truly-hard thing to get right, even with a lot of academic background.)




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

Search: