changed the subject to not distract from the main thrust of the original thread.
On Wed, May 18, 2011 at 11:44 AM, Mark Crispin <mrc+imap@panda.com> wrote:
> On Wed, 18 May 2011, Brandon Long wrote:
>>>
>>> 1. Allowing non-ASCII characters in keywords
>>
>> Note this is one of the main reasons we didn't map our labels to
>> keywords in the Gmail IMAP implementation. ?That, and the majority of
>> clients don't really expose keywords to the user in any real fashion.
>
> The problem is that in doing so, you forked IMAP in a way that causes
> trouble to compliant clients in this regard, and breaks compliant clients
> due to violations of the specification elsewhere.
I think this is a difference of opinion and not of fact. Obviously
Gmail and IMAP have different models of a mailbox, and our
implementation had to bridge these two models. You're implying that
we should have had folders which had no analogue in the web interface,
and we should have exposed IMAP labels as keywords and somehow solved
the same problem that this thread was asking about, perhaps as base32
encoded keywords. No client our users actually used would have done
anything with the keywords, and our users would have been presented
with a single folder with all of their mail in it, which for some
users would have been a million messages... and let me tell you how
well most clients handle folders of that size.
> This is deja vu of Microsoft's 1990s "Embrace, Extend, Destroy". The
> difference is that Microsoft's code has more bugs than a Manhattan
> basement. ?Google, on the other hand, just doesn't seem to care about
> compliance.
I wasn't aware that we were particularly out of compliance. I'm sure
that we are in some subtle ways, but the IMAP spec is fairly broad in
interpretation. There was no compliance test we could use as we were
developing the service, the best we could do was compare against the
clients we had access to, many of which have their own compliance
issues that we had to work around as best we could. We know about
http://imapwiki.org/ImapTest, though it came out after our initial
work. It looks like their last score for us from 3 years ago isn't
all that great, I had thought when I last looked at it we weren't that
bad, so perhaps it would behoove us to see what we can do about
improving that.
>> We do store keywords as labels which aren't visible in our web
>> interface, mostly because IMAP clients rarely used keywords to store
>> anything particularly user visible.
>
> That is the case if you define "IMAP clients" as Outlook and Thunderbird.
> Yes, I am aware that is the definition as used at Google.
At the end of the day, what our users care about is that the system
works for them. Strictly adhering to a spec that breaks things for
our users isn't a viable option. That said, those clients aren't
actually that high on the list, looks like they're 7th & 9th. Mobile
clients dominate, and Thunderbird is the second most popular desktop
client behind Apple Mail.
I'm sure there is some self-reinforcing in those stats, of course,
because a client that really doesn't work well isn't likely to be
used. Its also not easy to identify clients. The popularity of
mobile clients is also somewhat expected as most people would use the
web interface of a web mail product.
<snip>
> The extensions are not a problem so much as it is the other things.
> However, you could done that functionality within the framework of
> standard IMAP, without any extension; and then the functionality would be
> used by standard clients without requiring specific knowledge of Gmail.
As this thread points out, its not actually possible to handle unicode
label names as keywords without a bunch of challenges. Maybe if we'd
just started putting out ASTRINGs instead of ATOMs, no clients would
care, but that's certainly not compliant. It would also mean a
greatly increased bandwidth to give clients something they'd never
use. Already, the typical FETCH 1:* (UID FLAGS) command that many
clients use when they first open a folder can generate 6MB of download
on a 100k message folder, adding our labels as keywords would probably
double that.
> It just requires creativity and understanding; and the latter requires
> experience. ?Too bad that Google sacked Brian Reid.
Wow is that left field.
In any case, I'm happy to discuss our reasoning for particularly
implementation choices or incompatibilities. I'm also willing to file
bugs in cases where we're out of compliance by accident.
Brandon
--
?Brandon Long <blong@google.com>
?Staff Engineer
?Gmail Delivery TLM