Re: Four patches for LWP (and comments)
Martijn Koster (mak@victor.nexor.co.uk)
Mon, 07 Aug 1995 17:39:35 BST
In message <v02120d02ac4af2024f6f@[204.156.156.16]>, Marc Hedlund writes:
> Attached are four uuendcoded patches for LWP 0.2. 'patch.a' and 'patch.b'
> update LWP::StatusCode and LWP::MIMEheaders (respectively) to the August 3
> draft of HTTP/1.0, <draft-ietf-http-v10-spec-01.ps>, so they are strongly
> recommended.
Ah! you beat me to it :-)
> 'patch.c'adds the Response-Header fields to LWP::MIMEheaders,
> which may not be necessary within LWP but certainly makes that module more
> reusable (for me, at least!).
OK.
> 'patch.d' makes a change to
> LWP::MIMEheader's handling of unknown headers. I think it is an
> improvement, but it is not critical to anything I'm working on and could be
> omitted without complaint.
Yeah, that's nice. And thanks for putting in the "case insensitive" note
in the last draft Roy!
> Please note that these patches do NOT increment the RCS revision numbers of
> the files they modify. (Can someone please tell me what the standard
> practice for this would be? Should contributed patches mess with version
> numbers in any way, or should that be left to the maintainer(s)?)
Hmm, they're just going over this in perl-porters :-)
I'd just supply patches, the list can comment, and the maintainer with
the virtual token, which is Gisle, can roll over version numbers.
> * I completely agree that LWP::Date should be a standard Perl
> module -- there's no particular reason why it should be under the heading
> of LWP. How about Date::RFC1123?
Hmmm... How about a Date::Parse, which will parse any date known to
computing mankind, and then Date::{RFC1123,...} to output strings?
Note that the Date.pm is not perfect or complete. I nearly added a
fallback format parser, which guesses dates in any silly format such as
"1995 21 Jan 12:00 Wednesday" etc. That'd be neat (if fairly useless in
practice)
> The modules that support HTTP
> messages -- Message.pm, Request.pm, Response.pm, MIMEheader.pm, and
> StatusCode.pm -- are all tremendously worthwhile for response-based
> applications (like CGI scripts or mini-servers). They shouldn't be
> 'hidden' in a request-based distribution.
Yeah, I can agree with that, and the HTTP case makes sense.
> I remember Martijn saying something at one point like "just because a name
> space is available doesn't mean we own it."
My main point was we should not use WWW for the LWP model, and never put
LWP::Protocol::gopher into Gopher:: etc.
If the HTTP classes are divorced from the LWP model, there's no reason
they can't be put elsewhere.
> I advocate for, at least,
>
> HTTP::
> ::Message
> ::Request
> ::Response
> ::Headers
> ::Status
Yup, looks fine to me.
-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
WWW: http://web.nexor.co.uk/mak/mak.html