From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/16373 Path: main.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Newsgroups: gmane.emacs.gnus.general Subject: Re: Functional requirements for Gnus Date: 28 Aug 1998 10:37:23 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035155256 27395 80.91.224.250 (20 Oct 2002 23:07:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:07:36 +0000 (UTC) Cc: Steinar Bang , ding@gnus.org Return-Path: Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id KAA08148 for ; Fri, 28 Aug 1998 10:44:15 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id JAF09002; Fri, 28 Aug 1998 09:15:05 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 28 Aug 1998 09:43:50 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id JAA24291 for ; Fri, 28 Aug 1998 09:43:38 -0500 (CDT) Original-Received: from pluton.rtsq.qc.ca (pluton.grics.qc.ca [199.84.132.10]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id KAA08132 for ; Fri, 28 Aug 1998 10:43:28 -0400 (EDT) Original-Received: by pluton.rtsq.qc.ca (8.8.8/8.8.8) with UUCP id KAA15358; Fri, 28 Aug 1998 10:38:12 -0400 Original-Received: by icule.progiciels-bpi.ca (8.8.5/8.7.3) id KAA01183; Fri, 28 Aug 1998 10:37:25 -0400 Original-To: Kai Grossjohann X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m 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 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 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