Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Replace IMAP

gaborcselle.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: How to Replace IMAP

#41

Post by Nwallins »

Skeuomorph wrote: post #29

First, I love reMail. Gabor breathes email and search. If you own an iPhone and use Gmail or Google Apps, get reMail--you'll thank him. That said, it's easy to skim this article and nod, "Yeah! Yeah!", but when we're discussing these, laymen may need to know a few of these seem over-simplified. > "TCP connections are great, but for transferring large amounts of email securely, HTTP is the way to go." 1. http://wiki.a…

1.HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP.

Yes, of course. He is not claiming that TCP is bad, but rather that it is too low-level. i.e. One wants an application protocol (e.g. HTTP, SMTP, IMAP) rather than a transmission protocol (e.g. TCP).

The HTTP verbs should be sufficient for email, so why not leverage them?

It's not yet clear that people prefer tags to folders. After all, monkeys don't expect a banana to be in two boxes at once.

Heh, dare I reply? Tags can be used as pigeonholes, and this can be enforced if desired. But why? Tags are so much more useful because they are not pigeonholes.

Here is a classic example:

Does my app config go in a system directory or an app directory or a config directory? the executables? the daemon? the log files?

The classic approach is to put system-level config files under /etc, log files under /var/log, executables and daemons in various locations, etc. Some newer approaches (HomeBrew, GoboLinux, etc) keep everything organized per-application.

Instead, keep every file in the global folder / namespace. Tag the executables as exe, the log files as log, config as cfg, and also tag everything with the app's name. Possibly the version, etc.

A file is uniquely identified by its tags and its name. Any combo can be used, so long as it doesn't already exist.

You don't have to make painful decisions about the unique place in the tree that a piece of information should exist. Just tag it appropriately and move on. The tag system could even create an optimal concrete hierarchy based on tag and tag association metrics if needed.

But the server will have to know it to send it. Granted, IMAP is for receiving, and SMTP is for sending, but something in the chain has to know MIME.

I'm not sure if this is GoF, but this sounds like the classic gateway pattern. You put MIME gateways at the edges of the new email network. MIME-only servers must go through the gateways.

Re: How to Replace IMAP

#42

Post by PanMan »

edd wrote: post #36
IgorPartola wrote: post #24

Earlier quoted context omitted.

$mbox = imap_open( $host, $login, $password ); foreach( imap_search( $mbox, 'UNSEEN', SE_UID ) as $uid ) { $header = imap_fetch_overview( $mbox, $uid, FT_UID ); echo $header[0]->subject . "\n"; } imap_close( $mbox );

$status_url = 'http://twitter.com/statuses/user_timeline.json?screen_name='.$user; $timeline = json_decode(file_get_contents($status_url)); for($i = 0; $i text ."\n"; } One line in it then.

The count in the loop slows it down quite a bit:http://tips4php.com/2010/01/best-way-to-traverse-trough-an-a... Foreach is easier to write, and faster to run :)

Re: How to Replace IMAP

#43

Post by viraptor »

There are some good points, but:

1. HTTP / HTTPS - please don't... There are stupid/broken transparent proxies in many places that will effectively block this protocol. Also custom TLS connection gives some hope for domain-specific certificates instead of ip-specific - there is enough problem with them in HTTPS as it is.

3. People still don't know how to set the encoding (or what the encoding is) and will happily send you Greek in latin1 or something equally silly.

4. Would it really work for mailing lists where conversations naturally fork into many branches?

5. IMAP supports labels... even if it's crazy number-based labelling where every client needs to set its own names for the labels. We'd just need to make it not suck this time ;)

So it's not all that bad in IMAP - there are many areas where we can do worse by accident. But yes - it would be nice to have server-side text searching...

Re: How to Replace IMAP

#44

Post by eitally »

Nwallins wrote: post #41
Skeuomorph wrote: post #29

First, I love reMail. Gabor breathes email and search. If you own an iPhone and use Gmail or Google Apps, get reMail--you'll thank him. That said, it's easy to skim this article and nod, "Yeah! Yeah!", but when we're discussing these, laymen may need to know a few of these seem over-simplified. > "TCP connections are great, but for transferring large amounts of email securely, HTTP is the way to go." 1. http://wiki.a…

1.HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP. Yes, of course. He is not claiming that TCP is bad, but rather that it is too low-level. i.e. One wants an application protocol (e.g. HTTP, SMTP, IMAP) rather than a transmission protocol (e.g. TCP). The HTTP verbs should be sufficient for email, so why not leverage them? It's not yet clear that people prefer tags to folders.…

Your intended point about pigeonholes can sometimes backfire within the context of email. Consider a Gmail user who sends a query to a number of different recipients, expecting unique replies from each. Gmail, because of the like headers, will group all of the responses into the parent conversation. Let's say the users tags the first response with a label corresponding to that sender, and then the second response comes in. At this point, the user is at an "oh shit" moment, finally comprehending the implications of Google's labeling of conversations rather than individual messages.

You need to be able to specify both parent and child tags to be able to facilitate search and give users something that isn't too confusing re: organization.

Re: How to Replace IMAP

#45

Post by pyre »

viraptor wrote: post #43

There are some good points, but: 1. HTTP / HTTPS - please don't... There are stupid/broken transparent proxies in many places that will effectively block this protocol. Also custom TLS connection gives some hope for domain-specific certificates instead of ip-specific - there is enough problem with them in HTTPS as it is. 3. People still don't know how to set the encoding (or what the encoding is) and will happily sen…

> 4. Would it really work for mailing lists where conversations naturally fork into many branches?

I agree with this. The idea that messages must be accessed by conversation is a bit much. Support for conversation group could be nice, but ignoring that feature would have to be allowed so that clients could implement their own views.

For example, the following structure would be crappy to force on clients:

  Label
  `-> conversation 1
      `-> msg0
      `-> msg1
  `-> conversation 2
      `-> msg0
      `-> msg1
Needing to iterate through every conversation to pull tease out the full list of messages (in order to use a different conversation-grouping method) would be ridiculous. Not to mention the question of whether or not conversations should span labels and how that should work.

Re: How to Replace IMAP

#46

Post by Skeuomorph »

eitally wrote: post #44
Nwallins wrote: post #41

Earlier quoted context omitted.

1.HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP. Yes, of course. He is not claiming that TCP is bad, but rather that it is too low-level. i.e. One wants an application protocol (e.g. HTTP, SMTP, IMAP) rather than a transmission protocol (e.g. TCP). The HTTP verbs should be sufficient for email, so why not leverage them? It's not yet clear that people prefer tags to folders.…

Your intended point about pigeonholes can sometimes backfire within the context of email. Consider a Gmail user who sends a query to a number of different recipients, expecting unique replies from each. Gmail, because of the like headers, will group all of the responses into the parent conversation. Let's say the users tags the first response with a label corresponding to that sender, and then the second response com…

I understand the pigeonhole filing example, but I quit "filing" years ago. It's tedious. Tagging also takes too much thought, particularly at recall time: did I tag that "development" or "programming"? I just use search.

I have a script that monitors my desktop. Any file not modified within the past 8 hours is moved to a folder dated for the end of this week. That gives me 52 folders a year, granular enough to find a file manually if I know roughly when I dealt with it.

My desktop stays clean except for what I'm actively working on, and I don't look for files hierarchically or by category/tag. To find something, I use Spotlight search. That's faster than navigating a folder hierarchy would be even if I knew exactly where the file was.

That's also why I love Gabor's reMail on the iPhone.

Re: How to Replace IMAP

#47

Post by Nwallins »

eitally wrote: post #44
Nwallins wrote: post #41

Earlier quoted context omitted.

1.HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP. Yes, of course. He is not claiming that TCP is bad, but rather that it is too low-level. i.e. One wants an application protocol (e.g. HTTP, SMTP, IMAP) rather than a transmission protocol (e.g. TCP). The HTTP verbs should be sufficient for email, so why not leverage them? It's not yet clear that people prefer tags to folders.…

Your intended point about pigeonholes can sometimes backfire within the context of email. Consider a Gmail user who sends a query to a number of different recipients, expecting unique replies from each. Gmail, because of the like headers, will group all of the responses into the parent conversation. Let's say the users tags the first response with a label corresponding to that sender, and then the second response com…

> and then the second response comes in. At this point, the user is at an "oh shit" moment, finally comprehending the implications of Google's labeling

I am having trouble understanding what the problem is, here. I also suspect this may be a Gmail problem rather than a tagging problem.

Re: How to Replace IMAP

#48

Post by JeffJenkins »

gaborcselle wrote: post #31
JoachimSchipper wrote: post #18

This is a collection of the author's favourite technologies/gripes, not a useful proposal. A large number of errors can be found by considering that it'll have to talk SMTP on the back end. I'll only point to some "highlights". OAuth isn't nearly secure enough ( http://hueniverse.com/2009/04/explaining-the-oauth-session-f... ) for your e-mail (which, don't forget, gives access to everything via password resets). Let'…

Thanks for your suggestions Joachim! This is why I wrote that blog entry in the first place: To get some high-quality feedback. I think IMAP could be replaced independently of SMTP. You could conceivable replace an IMAP server with a reMAP server and not affect the rest of the mail ecosystem. SMTP will likely not die for another hundred years. 1. I know about the OAuth problems. Do you think we'll see a more secure s…

It's easy to validate UTF-8. The danger is if other implementations crop up that are more permissive and your users are complaining that they can't get mail from those people. I think you could probably manage to avoid that, but I don't know if it would really be preferable. I want to claim that in asia and europe there are some widely used non-unicode encodings used.

Re: How to Replace IMAP

#49

Post by [deleted] »

PanMan wrote: post #42
edd wrote: post #36

Earlier quoted context omitted.

$status_url = 'http://twitter.com/statuses/user_timeline.json?screen_name='.$user; $timeline = json_decode(file_get_contents($status_url)); for($i = 0; $i text ."\n"; } One line in it then.

The count in the loop slows it down quite a bit: http://tips4php.com/2010/01/best-way-to-traverse-trough-an-a... Foreach is easier to write, and faster to run :)

[deleted]

Re: How to Replace IMAP

#50

Post by JoachimSchipper »

qjz wrote: post #37
__david__ wrote: post #30

Earlier quoted context omitted.

With regards to search, I recently installed Cyrus Squatter for full text IMAP searching and it is blazing fast. To me it seems just as fast as any of the special case local searches I've seen people build (Spotlight/recent Thunderbirds).

Any new mail storage protocol should anticipate the need to store encrypted messages at rest. Sure, it can play a part by storing an encrypted index on the server to deliver to authorized clients, but all decryption and index updates should take place client-side with the user's private key. Stable UID's can help make this a reality. There is no reason to store messages in plaintext on the server, and no new protocol…

Message-IDs are already stable, though.
Post reply on HN