129 lines
5.0 KiB
Plaintext
129 lines
5.0 KiB
Plaintext
MBOX-Line: From dave at cridland.net Wed Nov 16 12:58:40 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
|
|
In-Reply-To: <CABa8R6tWSB-KTrcBm7Q71-7++Py3vKCe-WRGR04heaYWrGDzsQ@mail.gmail.com>
|
|
References: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com>
|
|
<alpine.OSX.1.10.1111141446070.8578@rastawifi.orthanc.ca>
|
|
<1321311798.30750.140660998918417@webmail.messagingengine.com>
|
|
<4EC1A0A5.8051.EFC2A39@David.Harris.pmail.gen.nz>
|
|
<1321346922.6321.140660999083661@webmail.messagingengine.com>
|
|
<4EC268D1.7010404@aol.com>
|
|
<1321364880.3715.140660999182809@webmail.messagingengine.com>
|
|
<alpine.OSX.2.00.1111151258420.38075@hsinghsing.panda.com>
|
|
<20111115233902.GA1071@brong.net>
|
|
<alpine.OSX.2.00.1111151543580.38075@hsinghsing.panda.com>
|
|
<D454A5E5-BEDE-47E6-909B-2C90463835EE@iki.fi>
|
|
<alpine.OSX.2.00.1111151800340.38075@hsinghsing.panda.com>
|
|
<29330.1321432388.123579@puncture>
|
|
<CABa8R6tWSB-KTrcBm7Q71-7++Py3vKCe-WRGR04heaYWrGDzsQ@mail.gmail.com>
|
|
Message-ID: <29330.1321477120.891382@puncture>
|
|
|
|
On Wed Nov 16 18:58:49 2011, Brandon Long wrote:
|
|
> On Wed, Nov 16, 2011 at 12:33 AM, Dave Cridland <dave@cridland.net>
|
|
> wrote:
|
|
> > On Wed Nov 16 02:24:17 2011, Mark Crispin wrote:
|
|
> >>
|
|
> >> My understanding is that Google perceived keywords as not
|
|
> commonly
|
|
> >> implemented, and thus needing to do view/mailbox mapping. It's
|
|
> been a
|
|
> >> major problem; a classic case of kludge tower building because
|
|
> it was
|
|
> >> perceived that they couldn't do it right to begin with.
|
|
> >
|
|
> > I thought this at one point, but I recall seeing somewhere that
|
|
> the
|
|
> > limitation was that keywords are pure ASCII, compared to mailbox
|
|
> names (and
|
|
> > Google tags or whatever they're called) which are full unicode,
|
|
> contain
|
|
> > spaces, etc.
|
|
>
|
|
> It was never really considered a viable option, because it wasn't
|
|
> technically possible with the standard, and because almost no client
|
|
> we looked at had any support for keywords (the most we saw was
|
|
> Thunderbird which uses like 6 keywords that mean various things, but
|
|
> doesn't even store them in IMAP as anything more than
|
|
> keyword1...keyword6, others only used it for things like spam).
|
|
>
|
|
> I'm sure there are some clients with better support for keywords,
|
|
> but
|
|
> they weren't common enough to make a difference in our decision.
|
|
>
|
|
>
|
|
Right, and I understand where you're coming from, which is why I
|
|
explicitly spelt out the mismatch here.
|
|
|
|
|
|
> > Personally I think Google are big enough that fixing this problem
|
|
> "properly"
|
|
> > (ie, a more free-text naming of FLAGS via the standards process)
|
|
> would have
|
|
> > been viable, but the desire of many companies (Google included)
|
|
> to assume
|
|
> > that marketing splash always trumps technical merit means that a
|
|
> kludge they
|
|
> > can release without consultation trumps revealing some portion of
|
|
> the plan,
|
|
> > or releasing incrementally, but with a better design.
|
|
> >
|
|
> > I do understand the pressure, and sympathize with it, but I still
|
|
> find it
|
|
> > annoying how little the technical argument counts for, especially
|
|
> when it's
|
|
> > a standardization issue, and these companies are often too happy
|
|
> to talk
|
|
> > about how much they support open standards.
|
|
>
|
|
> There are two separate things here: supporting the current standard
|
|
> and working to extend it.
|
|
>
|
|
>
|
|
Absolutely, and they're not in conflict.
|
|
|
|
|
|
> Our goal was supporting the current standard. Our primary
|
|
> motivation
|
|
> was access from mobile devices, where the IMAP clients are probably
|
|
> never going to receive an update. Designing our system to require
|
|
> extensive client changes to support us, even if those changes were
|
|
> "standard", was not a viable option.
|
|
>
|
|
>
|
|
No, you're missing my point.
|
|
|
|
I'm not saying that Google should have mandated a bunch of private
|
|
extensions bulldozered through a mockery of a standards process.
|
|
|
|
What I am saying is that had you offered a (potentially more basic)
|
|
IMAP service, but with an additional, well-designed extension to
|
|
handle the extended abilities of your message store, that would have
|
|
both enabled access, and in addition pushed the boundaries a bit (in,
|
|
I might add, a very sensible direction).
|
|
|
|
The fact is that if GMail supports something, clients are going to
|
|
follow - and demonstrably have done, implementing your quasi-LISTEXT
|
|
thing quite widely, I understand.
|
|
|
|
> Our goal was interoperability, which meant making Gmail look like
|
|
> IMAP
|
|
> as used by current clients. At the end of the day, the point of our
|
|
> service is to let people read their mail using the tools available
|
|
> to
|
|
> them.
|
|
|
|
Yes, but I don't see that the goal of providing reasonable service to
|
|
existing tools is in conflict with pushing to improve those existing
|
|
tools. And because Google is big, you can actually provide sufficient
|
|
encouragement to do so.
|
|
|
|
Dave.
|
|
--
|
|
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
|
|
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
|
|
- http://dave.cridland.net/
|
|
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
|
|
|