unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nic Ferrier <nferrier@tapsellferrier.co.uk>
Cc: emacs-devel@gnu.org
Subject: Re: Do you understand this?
Date: Tue, 08 Mar 2005 00:34:51 +0000	[thread overview]
Message-ID: <87hdjnotzo.fsf@tapsellferrier.co.uk> (raw)
In-Reply-To: <m1D8Rw4-0004RGC@rattlesnake.com> (Robert J. Chassell's message of "Mon, 7 Mar 2005 23:46:52 +0000 (UTC)")

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Jason Rumney rightly noted that
>
>     In the Emacs manual, we need to explain how the user configures
>     this in Emacs.  Describing what RFC2616 says is not very useful
>     ...
>
> Good point.  How about putting the explanation in a comment in
>
>     emacs/lisp/url/url-vars.el
>
> just after
>
> (defvar url-mime-accept-string nil
>   "String to send to the server in the Accept: field in HTTP requests.")
>
> ?  Or perhaps in the `Commentary:' section of 
>
>     emacs/lisp/url/url.el
>
> with some other remarks, too.  (I do not know enough to have any idea
> what the `other remarks' should say.)
>
>
> Here is the explanation, slightly changed from before, in a format for
> an Emacs Lisp library.  Please check this wording.  I think it is a
> little clearer than before.
>
>
> ;; An `Accept:' or `Accept-Charset' statement, or a `headers' as it is
> ;; often called, allows you, a client, to specify the priority or
> ;; weighing of the type of statement you would like a server to
> ;; accept.
> ;; 
> ;; In contrast to their precedence in English text, commas separate
> ;; _bigger_ groupings than semi-colons, which are used to prefix
> ;; weightings or priority values.  Priority values go from 0.0 to 1.0,
> ;; with 1.0 being highest.  When a priority or weighting value is not
> ;; listed the value is presumed to be 1.0.  Moreover, an `Accept:' or
> ;; `Accept-Charset' list need not be in priority or precedence order.
> ;; 
> ;; Thus, an accept statement such as
> ;; 
> ;;      Accept: text/plain;
> ;;              q=0.5, text/html, text/x-dvi;
> ;;              q=0.8, text/x-c
> ;; 
> ;; could be reformatted as
> ;; 
> ;;      Accept: text/plain; q=0.5,
> ;;              text/x-dvi; q=0.8,
> ;;              text/html ; q=1.0,
> ;;              text/x-c  ; q=1.0
> ;; 
> ;; This latter expression shows the list in order from lower to higher
> ;; priority.  Both `text/html' and `text/x-c' are of equal (and
> ;; highest) priority.
> ;; 
> ;; When a client sends in an HTTP request for a resource, the above
> ;; `Accept:' statement tells the server that the user prefers either
> ;; an HTML or text/x-c document.  If neither of those reprsentations
> ;; is available, then DVI is next preference.  If none of those three
> ;; are available, then plain text should be sent.  If neither plain
> ;; text, DVI, HTML nor x-c are available, then the server's response
> ;; should indicate that it is failing to find a representation that
> ;; satisfies the request.

I find this confusing. I understand what you are saying about commas
and semi-colons... but I think it is a red herring in terms of better
documentation. You seem to be trying to explain the HTTP rfc in an
elisp comment.

Why can't you just say:

 ;; An `Accept' or `Accept-Charset' header may be specified in the
 ;; form described in rfc2616 section 14.1 and 14.2.
 ;;
 ;; For example
 ;;        Accept: text/plain; q=0.5,
 ;;                  text/html,
 ;;                  text/x-dvi; q=0.8,
 ;;                  text/x-c


Personally, I think it would be better if this was automatic anyway,
as was indicated by the doc string in rms' original post. 

Normally I want Accept-Charset to be sent to an HTTP server based on
an automatically computed list from Emacs' available character sets.

The ability to configure Accept-Charsets specifically would be a rare
requirement and should not be encouraged in elisp programming.



Nic

  reply	other threads:[~2005-03-08  0:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-06 19:11 Do you understand this? Richard Stallman
2005-03-06 20:44 ` Nic Ferrier
2005-03-06 22:32   ` Robert J. Chassell
2005-03-06 22:58     ` Andreas Schwab
2005-03-06 23:05     ` Jason Rumney
2005-03-07 15:37       ` Robert J. Chassell
2005-03-07 17:10         ` Jason Rumney
2005-03-07 23:46           ` Robert J. Chassell
2005-03-08  0:34             ` Nic Ferrier [this message]
2005-03-08 18:41               ` Robert J. Chassell
2005-03-09 16:58                 ` Richard Stallman
2005-03-06 23:12     ` Nic Ferrier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87hdjnotzo.fsf@tapsellferrier.co.uk \
    --to=nferrier@tapsellferrier.co.uk \
    --cc=emacs-devel@gnu.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).