Re: Mulberry gone, now what?
- From: "Dave Cridland" <dave@xxxxxxxxxxxx>
- Date: 7 Oct 2005 13:26:46 -0700
usenet@xxxxxxxxxx wrote:
> Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, 7 Oct 2005, usenet@xxxxxxxxxx wrote:
> > > ... and suffers from the same problem as virtually every other IMAP
> > > client out there - it works best with a limited range of IMAP servers.
> >
> > "Works best with a limited range of IMAP servers", or "works best with
> > standards-compliant IMAP servers"?
> >
Actually, it works best with a server that hasn't yet been written.
Polymer supports a lot of extensions, and no server exists with the
full combination of extensions, yet.
Polymer should work with any IMAP4rev1 server. It might work with a
plain IMAP4 server, but I'd treat any errors there as low priority.
> > > Personally I think this is the fundamental flaw in IMAP, it's not
> > > tightly enough specified so IMAP servers vary quite a lot with the
> > > result that it's well nigh impossible to write an IMAP client that
> > > works well with them all.
> >
> > Can you point to anything in the IMAP specification that illustrates this
> > point?
> >
> See http://dave.cridland.net/acap/polymer.html for example where it
> says:-
>
Cool. Mark, see that? My webpage is a more important reference than the
specification. ;-)
> IMAP allows a great deal of latitude in much of the specification. As
> a result, some behaviour is rare, and relatively untested. As always
> with IMAP, you should select a server and client which interoperate
> well, supporting the features you require.
>
Latitude is definitely not intended to mean the specification is in any
way problematic. IMAP is very highly specified. It does, however,
provide various protocol features which allow server to behave
reasonably differently within some areas, in order to support very
different server-side mail spools. That's not a fault in the protocol,
that's a benefit. (One that has, in many respects, outlived itself). In
addition, there's exciting choices like multiple commands in progress,
unsolicited reponses at any time, etc.
These are minor little variations in the gran scheme of things, though.
The vast bulk of IMAP is very tightly specified - in some cases so
tightly specified that virtually nobody implements it correctly
(witness the \Recent flag).
> It then goes on to list IMAP servers that the client will work with,
> with varying levels of performance.
>
I think you're reading too much into that listing. :-)
> Many/most people won't have a choice of IMAP servers.
>
True, and Polymer will work with any standards compliant IMAP4rev1
server, or at least should do. If it doesn't, it's a bug in Polymer, no
question about it.
>
> My exeperience using mutt with different IMAP servers is that it never
> works quite the same with different servers.
Mutt is pretty basic in its IMAP support, so yes, server behaviour -
such as hierarchy - is directly visible to the user.
Polymer is not simple, nor basic, and attempts to make all servers
behave identically. It uses extensions such as NAMESPACE to do this,
emulates others where possible and prudent, and so on. The difference
visible comes down to performance, usually, either speed or bandwidth
consumption.
Polymer supports 21 IMAP extensions. (That's counting STARTTLS as an
extension, but not other capability strings mentioned in RFC3501, so
AUTH, LOGIN-DISABLED, etc).
Different servers support different subsets of these (and Polymer
doesn't yet support every IMAP extension, of course), so if you are in
a position to select either your server or your client - and many
people are in a position to do that - then my advice would always be to
consider which extensions and features you require, and make sure both
support them.
Moreover, I can't test every permutation and combination of extensions.
I can't test every possible combination of optional behaviour in
RFC3501. Like, for instance, servers sending FETCH or EXISTS responses
when no command is in progress, even if they don't support IDLE. It's
legal, but nobody does it. Hardly any clients can cope, either, but
Polymer can, just as it can cope with commands executing out of order.
And different support on the server means that potentially different
features become available, (unlimited keywords? ANNOTATE?). Polymer
can't easily emulate message metadata (I could map it onto ACAP, but
it's rather messy), so some features are dependent on server behaviour.
I happen to have opted to list the servers I happen to have tested
relatively recently and reasonably extensively, and can continue to
test on a frequent basis, in an order which makes sense for my
technical requirements.
Note that the last entry is "Other Servers" - I do know that Polymer
works perfectly well with UW-IMAP, for instance, because UW-IMAP
conforms to RFC3501 etc. I've not put UW-IMAP on that list, because it
happens that I don't have an account on such a server.
I hope that clears up any misunderstanding.
Dave.
.
- Follow-Ups:
- Re: Mulberry gone, now what?
- From: Mark Crispin
- Re: Mulberry gone, now what?
- From: usenet
- Re: Mulberry gone, now what?
- References:
- Mulberry gone, now what?
- From: Yiorgos Adamopoulos
- Re: Mulberry gone, now what?
- From: kael
- Re: Mulberry gone, now what?
- From: usenet
- Re: Mulberry gone, now what?
- From: Mark Crispin
- Re: Mulberry gone, now what?
- From: usenet
- Mulberry gone, now what?
- Prev by Date: Re: Mulberry gone, now what?
- Next by Date: Re: Mulberry gone, now what?
- Previous by thread: Re: Mulberry gone, now what?
- Next by thread: Re: Mulberry gone, now what?
- Index(es):
Relevant Pages
|
