Re: Functional requirements for Gnus

["François Pinard" <pinard@iro.umontreal.ca>]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> (1) `The TM alternative'
> (2) `The digest alternative'
> (3) `The X u alternative'

Nice summary, thanks!

Before going on, let me compare (2) and (3) a bit more.  The mechanics in
(3) has the advantage of letting users have a default action associated
with each recognised part, which the user could later easily trigger.
One disadvantage is that the mechanics is not currently set for handling
deep hierarchical structures as sometimes found in MIME messages, another
disadvantage is that only one action is defaulted for each part, a last one
is that it abuses temporary files.  All these could be corrected, of course,
but (2) easily beats (3) on these points, and rather elegantly.  Deep MIME
hierarchies could be presented by blending them with article threading,
for which Gnus already has a lot of nice features.  Considering that each
part in (2) may already be turned into a complete and valid MIME message,
we have a rich set of actions that Gnus offers for handling them.  Finally,
the `nndoc' mechanism in (2) is such that we can postpone the creation of
temporary files as much as needed.  For all these reasons, despite (2) and
(3) could be made to reach similar goals, I would not consider (3) further.

In my opinion, the choice between (1) and (2) also depends on what one
intends to do with a MIME message.  Briefly said, the possible actions
may be regrouped into four categories.  Note that MIME handling could be
overall split into composition and reception, I'm only discussing reception
issues here.  The problem of reassembling split parts, which has its own
difficulties, is not addressed either (yet `rmime.el' does it very nicely).

(A) `Presentation'

The usual, default action does with non-MIME messages is to present them
in an Article buffer, and the presentation problem for MIME messages is
to use paradigms closest to the "normal" Gnus operations.  Presentation
of MIME messages should be bound to the already existing mechanics for
washing, hiding and highligting articles.  Plain texts would require no
transformation, reference to external bodies could be turned into clickable
references in messages, enriched text could be highlighted appropriately,
foreign charsets could be displayed using fonts already available within
Emacs.  MIME-specific headers would be hidden, and the details of the
presentation could be decided by a mix of washing/hiding options, selectable
by hooks most probably, as it is done for other washing capabilities.

MIME boundaries between entities are very thick and paragraph oriented, while
HTML may really be inlined within sentences, not even requiring line breaks.
Despite this ugliness of MIME, and seen under the proper angle, MIME and
HTML both aim unified presentation.  My guess is that Gnus should try to
somewhat hide the fatness of MIME instead of consecrating its heaviness,
trying its best at making MIME looking as light as possible.  For example,
one hardly think that an HTML browser should give the opportunity of seeing
an image, without seeing the whole page containing it, and I'm tempted to
look at a MIME composite message the same way.

For presentation, there is not much choice, and (1) `The TM alternative'
is the main way to go.  However, you may consider that (2) `The digest
alternative' is appealing for some big MIME messages, as we would rather
like to concentrate on a hierarchical subset of it, like applying a lense
for close-up.  In a complex hierarchy of entities (not seen often yet,
but it happens sometimes, and might happen more frequently as the community
will continue learning how to use MIME), there is a need for looking at some
intermediary part of a MIME tree, that is, more cleverly that strictly at
the root or at a leaf.  Presenting a node of a tree of MIME entities also
implies the presentation of all sub-nodes of that node.  `nndoc' already
does this correctly.  Yet, even if (2) allows users to select the viewpoint
of their choice, it remains that (1) has to be used for presentation.

(B) `Performance'

The difference between presentation and performance is the dynamical aspect,
as a sound cannot be "displayed" statically, and a movie could not usually be
in Emacses.  If a message contains "And I replied: [sound saying `Hello']",
it would make sense thinking of the sound as static only if we had means to
measure the eye movements of the users, and have `Hello' heard each time the
eyes traverse the colon in the said (sic :-) quote.  This cannot be easily
be done, it is better to consider performance as separate from presentation.

Of course, one might try hard to spare the necessity of separate performance.
For example, one might use the cursor for approximating the eye, and
merely moving the cursor could trigger presentation of dynamic elements.
But to be honest, I'm not sure how appropriate this would be.  If we cannot
think of something really reasonable, and I'm not sure we can, it would be
best to accept once and for all that merging presentation and performance
should just not be attempted.  Of course, this does not prevent users
to hope being able to trigger performance from within the presentation,
but these issues are separate.

(C) `Extraction'

Roughly said, extracting/saving a whole MIME message already works in Gnus,
as a MIME message is also a generic message, which Gnus know how to handle.
Extracting and low-level examination -- point (D) -- in MIME contexts,
have this in common that they want to break down a MIME structure into
separate entities that could be handled separately.

Extracting and low-level examination (below), in MIME contexts, have this in
common that they want to break down a MIME structure into separate entities
that could be handled separately.  I do not deny that the extraction need
exists, but I would like to stress a bit that too often, the need is a
consequence of the weakness of the presentation or performance tools.
For example, one hardly think that an HTML browser should give the
opportunity of seeing an image, without seeing the whole page containing
it, and I'm tempted to look at a MIME composite message the same way.

All this to say that extraction of MIME parts is somewhat unrelated to
presentation.  Once again, nothing prevents extraction to be triggered
from within presentation, like in (1) `The TM alternative', but this time,
it would be better be done from (2) `The digest alternative'.  I mean
that the real proper way is (2) for selecting a leaf to operate upon,
but this does not prevent (1) from offering convenient short-cuts.

(D) `Examination'

Message examination is needed rarely, for those wanting to see the intimate
structure of a somewhat unprocessed message, for debugging or understanding,
or other low-level operations.  Gnus already have tools for looking at a raw
message, and my guess is that those tools are all sufficient already for
MIME messages.  The only problem might be to concentrate the examination
on a specific MIME part, and (2) `The digest alternative' offers what is
needed to select a viewpoint in the MIME tree.  It would be overkill and
a bit pollution to bring such considerations into (1) `The TM alternative'.

David Hedbor <david@hedbor.org> writes:

> Another benefit with #2 compared to to TM system, is that with TM-style
> viewing, if you get a mail with 10 images (which happens to me now and
> then), displaying the message is very slow and use a lot of resources.
> Viewing one image at a time, in a "attachment buffer" would be much nicer.
> [...] Whether or not the text should be inserted could be configured
> with a variable [...]

Of course, (1) `The TM alternative' should be hookable and parameterisable at
will, and part of the implementation difficulty is be to reach a meaningful
set of options that would make most people happy.  The default behaviour
of Gnus, given a MIME message, should become highly tunable in the long run.

Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes:

> You seem to be mainly concerned with multipart/mixed.  What about
> multipart/alternative?  m/digest, m/parallel, m/related should probably
> be treated much like m/mixed.  There are also multipart/signed,
> multipart/encrypted, which should be handed over to mailcrypt.

Things become a bit simpler when one identifies the user intent, as
processing choices might differ.  To summarise the above:

> (1) `The TM alternative'
> (2) `The digest alternative'
> (3) `The X u alternative'

> (A) `Presentation'
> (B) `Performance'
> (C) `Extraction'
> (D) `Examination'

If we consider multipart/alternative, for example, it looks clear than
(A) and (B) requires an alternative to be automatically taken, or else,
looking at MIME messages would be unduly cumbersome.  But for (C) and
(D), this is quite different: all alternative parts should be explicitely
available.  Since (2) gives a finer (and fine :-) control on selection,
it would be helpful when in an alternative situation even for (A) and (B).
On the other hand, we should not loose sight that multipart/alternative
could open the door to fairly complex structures each, not even similar.
It would not be appropriate to mix selection menus within (1), or if we
ever try to do so, we might be preparing for some miserable situations at
some later time.

To summarise this longish message, I merely think that our best bet has
to be a mix of (1) `The TM alternative' and (2) `The digest alternative'.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard