On 8 Feb 2017, at 9:52, Ted Lemon wrote:
IMAP and POP both use the wrong data abstraction, and consequently are
very hard to get right, and generally aren't gotten right.
So a new protocol that has the data abstraction right is actually a
substantial improvement. I don't know if that's the case with
JMAP—if it's the same data abstraction as IMAP, it's not worth
bothering with, but that's something that at least in theory can be
discussed.
What JMAP does afford is the opportunity to have an embedded web
client that doesn't suck, and a way to escape it if you want something
more stateful.
Yep, this is the bit that convinces me that this effort should go
forward. IMAP's problem has always been its combination of semantic
bottleneck and leakage: It constrained the semantics that you could
communicate across the pipe in some ways (hence the myriad of extensions
required to have a workable IMAP implementation), but leaked a bunch of
server-specific semantics (e.g., the storage model, the constraints on
network resources) through to the client instead of having a clean
protocol. Putting a rich and leak-free protocol in front of IMAP is an
improvement, and being able to remove IMAP from the equation eventually
is a laudable goal.
Yes, there are transition and conversion issues. But I haven't heard
anyone come up with a solution to the problems inherent in IMAP that
doesn't involve transition pain. The answer can't simply be, "Never
attempt to solve the IMAP implementation problems" or "Only solve IMAP
implementation problems within IMAP". Neither one of those answers leads
to a solution.
(BTW: The submission issue seems a rather boring one to me. There's
never been good deployment of BURL and the other LEMONADE mechanisms to
make it happen. If this work just creates a decent protocol interface to
those submission mechanisms, more power to them. I don't think there's
anything magical here.)
I have no objection to clarifying the charter in many of the ways
suggested to make clear what the motivations are and what the
constraints are on the work, but overall I think this effort should go
forward.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478