Re: What Is Wrong With Newswatcher?

On Oct 6, 10:24 pm, Sandman <m...@xxxxxxxxxxx> wrote:
ed <n...@xxxxxxxxxxxxxxx> wrote:
Sandman:
But the recommendation is based on the RFC-based limit of 1000
chars that demands the client to hard wrap the lines either
way. While 1000 chars is a lot, it's still not impossible for
a paragraph to be 100 chars.
Ed:
of course it's not impossible.  but always wrapping, versus not
breaking links that are shorter than 1000 chars, seems like a
poor design choice.
Sandman:
MT-NW doesn't "break links", it wraps according to RFC's, it's the
receiving end that can't handle hard wrapped url's. MT-NW can, of
course, especially if you enclose it in brackets (another
standard)
Ed:
can you post a long url from mt newswatcher (or a long block of text
in general)- i don't recall mt-nw doing anything special, and i
don't recall brackets being a standard in the rfc to enclose wrapped
lines- what spec is that standard from?

Brackets is a standard for enclosing links:

<http://sandman.net>

And MT-NW handles hard-wrapped long urls without a problem:

<http://groups.google.com/groups/search?q=see+how+MT-NW+handles+long+ur
s+without+a+problem&qt_s=Search+Groups>

the fact that you don't list a spec suggests that it's a informal
standard? and what happens if mt-nw encounters a url like the
following and you try to wrap it in brackets and it wraps?

http://www.atwistedweb.com/test/blah>.html

You can, of course, tell MT-NW not to wrap at all, but this is where
it's pretty buggy (or rather, poorly implemented), where text will
grow outside the window width. MT-NW doesn't soft-wrap text.

furthermore, doing a more careful reading of 3977, you're
misinterpreting what multi-line responses deal with- it's for
responses that have multi-lines (list groups, article, etc), not for
breaking a long line into multi-lines.

I don't know why you're bringing this up,

um, because you listed that rfc and quoted the portion regarding multi-
lines. :P

the NNTP RFC is the only
place which doesn't impose any line length rules at all (i.e. the only
one that supports you). This was covered in my initial round-ups of
RFCs that apply. Either way, I didn't minsinterprete anything with
regards to multi-line blocks:

3.1.1.  Multi-line Data Blocks

   A multi-line data block is used in certain commands and responses.
   It MUST adhere to the following rules:

   <snip rules>

   This document does not place any limit on the length of a line in a
   multi-line block.  However, the standards that define the format of
   articles may do so.

Certain commands and responses are, for example, the POST command,
that posts an article, meaning that multi-line blocks most certainly
applies to messages that you post:

multi-line blocks pertain to the contents of the post, which will
obviously contain multiple lines. it most certainly does NOT apple to
wrapping rules, which is the context of this discussion- if you didn't
mean it in that context, why did you bring it up?

6.3.1.  POST

6.3.1.1.  Usage

   <snip>

6.3.1.2.  Description

   <snip>

   If posting is permitted, the article MUST be in the format specified
   in Section 3.6 and MUST be sent by the client to the server as a
   multi-line data block (see Section 3.1.1).

I.e. you can not send a POST without using the multi-line block
standard.

yup. and it's irrelevant to wrapping, other than that wrapping will
naturally result in multi lines. the standards defined for specifying
the beginning and ending of the blocks pertain to the commands and
responses, not individually wrapped sections. i.e. irrelevant to the
discussion, so why did you bring it up.

It should be noted here that I've written a (far from complete) NNTP
implementation in PHP a long time ago, so I've actually studied these
documents in the past.

and i've written one in java. :P
.

Relevant Pages

  • Re: RfD: c-addr/len
    ... Then I wonder why you are asking us to get rid of CHARS ... encodings and MIME, when common practice is using MIME. ... Thus what we see for now, you design standard, you make another series ...
    (comp.lang.forth)
  • Re: C90 penetration
    ... and just specify that the "precision" ... A bit-field whose size is CHAR_BIT, can certainly be represented by a char; bit fields of a larger size clearly cannot be represented as a single char. ... Also, the standard requires that if a bit field with a width of 3 is followed by a bit field with a width of 4, then if there's enough room in the allocation unit, they must be allocated in adjacent bits within that allocation unit; that's pretty hard to do if you implement them as chars. ...
    (comp.lang.c)
  • aus and chars (was: CMOVE wrong?)
    ... (except on word-addressed machines). ... : ALLOT CHARS ALLOT; ... future standard systems (apart from that demonstration system by Jack ... based on) are also variable-width with byte granularity. ...
    (comp.lang.forth)
  • Re: char and au size
    ... 1, and all supported Forth-94 systems implement this, so it might be a ... supports several platforms for which chars and AU are different, ... So we won't see standard systems on such small machines, ...
    (comp.lang.forth)
  • Re: clock() function
    ... > "The clock function returns the implementation’s best approximation to the ... > below) wrap, so storing that in a double won't help, and the period the OP ... Neither the standard nor the previously quoted documentation provide ...
    (comp.lang.c)