Gnus development mailing list
 help / color / mirror / Atom feed
From: mah@everybody.org (Mark A. Hershberger)
Cc: Klaus Straubinger <KSNetz@Arcor.DE>
Subject: Re: nnrss-request-article produces multipart articles
Date: Tue, 06 May 2003 12:12:41 -0500	[thread overview]
Message-ID: <87r87cov7a.fsf@batman.everybody.org> (raw)
In-Reply-To: <m3el3d3b12.fsf@P54276.Wdf.SAP.Corp>

Klaus Straubinger <KSNetz@Arcor.DE> writes:

> Due to some last-minute changes before the release of Gnus 5.10.1, the
> function nnrss-request-article now produces multipart/alternative
> articles. The reason given for this change was to avoid some
> unspecified problems with w3m. In my view, this is no sufficient reason
> for such a change. nnrss should always produce text/html articles since
> RSS sites use XML/HTML as output format.

Yay! Competing feature requests.

RSS feeds do not always contain embedded HTML.  In fact, the 
many people strongly urge that <description> elements not contain
anything except plain text[1].  Other nnrss users complained when I
made the default a single text/html.  The multipart/alternative lets
you choose.

FWIW, there are at least four different ways that content is put into an
RSS feed.

<description> -- Strongly suggested that new feeds just put plain
  text here, but historical use means there are a lot of feeds with
  encoded HTML.  Often this is just an excerpt of the full piece.
  Some people put a short summary here.

<content:*>, especially <content:encoded> -- Encoded markup.  Often
  contains the full content of the item.

<xhtml:body> -- The full content in all its un-encoded XHTML glory.

<content:items> containing <rdf:value> -- The full content in all its
  un-encoded XML glory.

I'd love for nnrss to support all of these.  In fact, since many feeds
contain <description> (plain-text) and one of the other methods, I'd
like to put <description> in a text/plain part and the others in a
text/html part if more than just the <description> is present.

>   - instead of producing multipart headers manually, an analogon to
>     the function mm-insert-multipart-headers should be created and used.

Thanks for letting me know.  This is the sort of thing where a Gnus
developer manual would help.

I'll fix some of the problems you mentioned tonight.

Mark.

Footnotes: 
[1]  http://www.textism.com/article/553/
     http://philringnalda.com/blog/2002/09/rss_10_contentencoded.php
     http://www.peerfear.org/rss/permalink/1028943207.shtml
     http://revjim.net/archives/2002/09/25/c3818.php

-- 
You are a mystery as deep as the sea; the more I search, the more
I find, and the more I find the more I search for you.
	    -- St. Catherine of Siena



      reply	other threads:[~2003-05-06 17:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-05 11:09 Klaus Straubinger
2003-05-06 17:12 ` Mark A. Hershberger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r87cov7a.fsf@batman.everybody.org \
    --to=mah@everybody.org \
    --cc=KSNetz@Arcor.DE \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).