lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Internal MIME types


From: Foteos Macrides
Subject: Re: LYNX-DEV Internal MIME types
Date: Sun, 27 Apr 1997 19:57:02 -0500 (EST)

Klaus Weide <address@hidden> wrote:
>On Sat, 26 Apr 1997, Wayne Buttles wrote:
>
>> On Sat, 26 Apr 1997, Al Gilman wrote:
>> 
>> > Orthogonalizing different dimensions of the content is moving in
>> > the right direction, in my view, because of my assumptions about
>> > the form of the solution to the access problem.
>> 
>> OK, I don't think I have said anything up till now but I can't hold out
>> any longer.  I have no idea what you are talking about most of the time.
>> What does "Orthogonalizing different dimensions of the content" mean?
>> 
>> I feel very under-educated reading your posts.
>
>You are not alone :)
>
>I am just trying to play along and try to make sense of it.
>
>Can I ask you a favor?  Please let me know in case I also sound like that.
>I don't want to.  [And I'm wondering what Fote's lots-of-smileys mean...]

        My smileys were intended to indicate that though I strongly
disagree with

        [1] the extreme to which you are taking the issue of adherence
            to standards, even when they disagree with what the great
            majority of deployed browsers do (not just Netscape and
            MSIE), and thus are of dubious validity within the IETF's
            own requirements that it's RFCs reflect "consensus" and
            formalize "current practice" (They are not commandments
            written in stone.),

        [2] the manner in which you are promoting them (which, IMHO,
            penalizes the Lynx users by causing failures of access due
            to sins of the document authors, rather than promoting
            successful access coupled to statusline messages which
            might help get the "bad stuff" in the authors' documents
            corrected,

        [3] the logic of your recent, substantial additions to the
            devel code for resolving fragments, for showing just the
            fragment versus full URLs in the advanced statusline or
            showinfo display, and for regulating re-use of cached
            HText structures (which in my view is flawed to the extent
            of representing "serious bugs" in the devel code, and
            increases the memory requirements needlessly, to do things
            that often shouldn't be done),
            
you, nonetheless, should perceive what I wrote/write as "friendly
criticism", particularly because the role of de-facto coordinator is,
IMHO, very import if Lynx development is to remain viable and coherent,
and I feel on edge about criticizing within the context of your oft'
expressed caveat that you might stop coordinating at any time (i.e.,
before the devel code is brought to a formal release).

        My longest string of smileys was for my criticism that your
"Why does Lynx do this" draft was verbose, reflecting, I assumed, the
passion with which you feel that Lynx should apply, carte blanc, the
RFC1808 and Fielding URL draft parsing rules, and fail, rather than
applying a "map /../* /* rule plus a redirection equivalent for
http/https URL resolving, as just about all other browsers now do,
PLUS a statusline message about the bad partial reference, as,
unfortunately, the other browsers don't -- because many **but not
all** users, i.e., only those in accounts with 'g'oto enabled, could
jump through the hoop of inspecting URLs that return a 304, notice
if they are http/https URLs with a lead relative symbolic element,
and enter it manually without that lead element.  Also, because you
had previously critized Al for using too many "buzz words" in his
messages, particularlly the verbose ones, I tried to make a perhaps
esoteric joke by saying that your verbose treatise *is* understandable,
without buzz words (like "Orthogonalizing different dimensions of the
content" instead of plain English for saying that the character
attribute/style tags, form fields, and formally styled "container" 
HTML elements are being treated as relatively independent).

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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