lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Revised patch for HTFTP.c


From: Klaus Weide
Subject: Re: lynx-dev Revised patch for HTFTP.c
Date: Tue, 22 Aug 2000 00:48:28 -0500 (CDT)

On Mon, 21 Aug 2000, Henry Nelson wrote:

> > Maybe it's not so good that lynx treats files of completely unknown type
> > (no suffix mappings) as text/plain by default.
> 
> If it's "not so good" why not have Lynx transfer all files of "completely
> unknown type" in binary?  

What exactly do you mean?  why not ...

 (a) keep treating content as text/plain, but *transfer* in binary mode;
 (b) treat content as something else (application/octet-stream), and
     also transfer in binary mode?

Anyway, my personal answer to the question "why not change it?" is:
I am very hesitant to change a long-standing default if there is no
clear advantage (or error correction).  If the file is rendered internally
by lynx, it has to be treated as a text/plain or text/html type.  And in
that case, ASCII transfer mode is appropriate (I know, DK disagrees, at
least for some cases). If you want binary *transfer*, then it's only
consistent to also treat it as *binary content*, i.e. not render it in
lynx at all but provide a download prompt (or maybe call an external
viewer).

So that change of default, in the way of understanding it that makes sense
to me, would make some files non-renderable (user gets 'd' offer instead).
Complaints are foreseeable.  Heck I would complain.

> Doesn't a binary transfer mean that the file
> received by the client is "exactly" the same as the file that resides on
> the server?  It seems that with that file in hand the user of the client
> could do whatever he/she thinks is best to do with it.  (I think Klaus
> already said something like that somewhere.)

But sometimes "whatever he/she thinks is best" is not what he/she wants;
or rather, he/she thinks that he/she should not have to think and do
at all, but let lynx "do", by just rendering the file contents.  After all
that may be the only reason why the user is using lynx and not some
plain old Unix ftp...

> I'm a little interested in this area, but don't rely on Lynx a lot for
> ftp, though I might if I didn't (granted from _past_ experience) find
> plain ol' Un*x "ftp" so much more reliable.


  Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]