Re: Sending attachments

[Miles Bader]

"Alfred M. Szmidt" <address@hidden> writes:
>      (1) We must still maintain message-mode as well, so mail-mode's
>        "simplicity" yields no obvious code maintenance Benefit.
>
> Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
> vs. mh (which each has their own mail sending mode!), viper
> vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.

For all of the above, the duplication _does_ cause additional
maintenance burden, and more user confusion.

However, for many such packages the UIs of the various alternative modes
are quite different, so it's much easier to argue that the alternatives
are all "necessary" (in some cases that may not be true -- e.g., I'm not
sure if vi-mode is still really necessary), and that the burden is
justified.

mail-mode vs. message-mode is a particular funny case because the
message-mode UI seems to be pretty much a superset of mail-mode's UI
(if it isn't, please give details).

ERC vs. rcirc is a case where ERC is more functional, but has a very
different feel to the user.  My vague sense is that maybe people are
saying they feel the same is true of mail-mode vs. message-mode, but in
my own experience, such a difference was not at all obvious.

> You already have people who prefer it, and are more than happy to fix
> any bugs it has.

So, tell me, in concrete terms, _why_ do they prefer it?   Well, OK, you
may not want to speak for others, so just tell me why _you_ prefer it?
How would you be adversely affected if one day, someone snuck up and
replaced mail-mode with message-mode?

To help you get started, here are a general categories:

 (1) UI differences (AFAICT, they're very very similar, but I'm sure
     there are some differences that annoy people -- though in some
     cases these are probably bugs...)

 (2) Customization/hook differences -- maybe mail-mode has some great
     hooks or settings that message-mode doesn't.

 (3) Behavioral differences -- does mail-mode work with some systems
     where message-mode doesn't (as I mentioned earlier, mail-mode fails
     to send for some reason on one of my machines)?

Remember, be concrete, and be detailed -- we've all argued enough that
people's basic position is clear enough, and I don't see how it's
possible to advance this discussion without some actual details...

The reason why I sound a bit incredulous is that I've used both, and
other than message-mode's extra functionality -- which seemed pretty
much invisible to me unless I needed it -- they seemed more or less
identical.  [Well there are some things, like the fill prefix when
filling a header line is different...]

> Maintenance is clearly not the issue here.

Both modes seem fairly mature, so it's not the problem it might be, but
any bugs need to be checked for in both modes, and any new features may
need to be thought about in the context of both.  Documentation needs to
consider both, and worry about making the difference clear to users.
But I agree, it's probably not the main issue (though in the abstract
it's Not Good to have duplicate code bases).

I think, however, that the user burden of the duplication is very real.
People do not know, in general, that to get certain functionality they
have to use a different mail-sending mode.

>        Indeed, it's obviously more of a _burden_ to maintain both
>        modes than it is to maintain message-mode alone (in the case
>        that we got rid of mail-mode).  This burden goes up, of
>        course, if mail-mode starts getting more features, like the
>        suggested attachments.
>
> For such a feature to be properly implmented they wouldn't be in
> mail-mode (or any such mode), but in a seperate mode that handles MIME
> attachment exclusivly.  If message-mode handles this itself, then it
> is a sign that it was not properly thought through.

That is not at all clear -- AFAIK, much of the actual MIME stuff is a
separate library, but MIME covers a lot of aspects of mail encoding, not
just attachments, and all of that it's going to need to be hooked into
the top-level mode.

In any case, I can't defend the quality of the message-mode code.  The
general code quality or design of mail-mode may well be higher.

However, if mail-mode doesn't have the requisite functionality (which
certainly seems to be the case), then we could

 (a) Keep both, and suffer the problems of having both (maintenance
     burden and user confusion).

 (b) Fix any bugs / functional inadequacies in in message-mode, and
     trash mail-mode.  Since message-mode largely seems to be a superset
     from the user's point of view, this option seems to have a fairly
     small cost.  If message-mode's code is bad, then that's a shame,
     but having message-mode alone is certainly less of a problem than
     message-mode plus something else.

 (c) Add the required functionality to mail-mode, fix any other problems
     with it, and trash message-mode.  As mail-mode is missing a lot of
     functionality, this would seem to have a far higher cost than
     option (b), but the end result might be better.

If mail-mode has better code than message-mode, then ideally we'd choose
(c), but in practice, the implementation cost (and associated extra
maintenance burden of new code) may make (b) the better choice.

> I use it every day for non-ASCII text, and mail-mode has not had any
> problems with that.

The most obvious problem with mail-mode's handling of non-ASCII text is
that it doesn't seem to encode headers correctly (headers in email are
annoying, you need to use a whole separate system for encoding them).

[and does mail-mode support any non-8-bit transfer encodings?  Does it
work if the message encoding isn't utf-8, and the user uses multiple
languages?]

Thanks,

-Miles

-- 
Erudition, n. Dust shaken out of a book into an empty skull.