Comments on LWP from a Mac user
Paul Schinder (schinder@pjstoaster.pg.md.us)
Sat, 05 Aug 95 23:29:40 -0500
I have some comments on LWP. I've had some time this weekend to go
through some of it in preparation for porting it to MacPerl, as I did with
libwww-perl-0.40. (I'm hampered for the moment by the fact that MacPerl5
for Motorola 680x0 based Macs doesn't exist yet and that I left my ream of
Perl 5 manual pages from my Sun workstation 200 miles away). I don't know
whether you intend LWP to be easily portable to anything other that
machines running Unix. If not, simply ignore this.
The (few) problems I had with libwww-perl had mostly to do with the
following: 1) assumption that \r\n meant \015\012. On a Mac, it
doesn't (\r\n = \012\015), and I had to track down all occurences of
\r\n and replace them with what was actually required, \015\012. 2)
the assumption that every filesystem is a Unix filesystem, 3) use of
alarm(). I had to write two routines, which I called macify and
unixify, to covert paths from URL's to actual Mac paths for use in
operations on the local file system, or from Mac paths to paths which
can be placed in the $path slot of a URL. The alarm()'s simply got
commented out and haven't been a problem.
I notice the some of the same sorts of problems in LWP. For example, in
LWP::Protocols::http, there's $endl = "\r\n";. In LWP::Protocols::file,
there's an assumption that you can immediately take the $path part of the
file: URL and do a -e, -r, etc. on it. What's needed here (or in fact, in
URI::URL if you insist on using fastcwd(); the path
"Macintosh HD:MacPerl5_scripts:lwp-0.20:" wouldn't work too well in a URL)
is a way of converting names from the local to the network file system,
say localtonet() and nettolocal(). These would, of course, be no-ops
on Unix machines and would need to be defined for each individual
architecture. Since my knowledge of Perl 5 up to this time has been
limited to installing it on several Unix workstations, running the
tests, and then mostly ignoring it, I'm not sure how best this should
be done. It would be nice, though, if hooks for it could
be included in URI:: and/or LWP::, say in a URI::local. Something
should also be done about the directory -> HTML routine in
LWP::Protocols::file, since it assumes that the directory separation
character is "/". As an example of what I mean, here's the diffs
between file.pm and the hacks I made to it that should work on a Mac
(given writing nettolocal and localtonet), similar to the changes I've
made in libwww-perl-0.40's wwwfile:
64,69d63
< #
< # MacPerl 5 change; note $path should not end in :, because one is added on
< # below
< #
< my $netpath = $path;
< $path = &nettolocal($netpath);
112,118c106,107
< #
< # MacPerl 5 change
< #
< # $_ .= "/" if -d "$path/$_";
< $_ .= ":" if -d "$path:$_";
< my $netname = &localtonet($_);
< $_ = qq{<LI> <a href="$netname">$_</a>};
---
> $_ .= "/" if -d "$path/$_";
> $_ = qq{<LI> <a href="$_">$_</a>};
Of course, the second chunk would only work on a Mac and should
probably be done in some more portable fashion
The self-tests I've looked at are mostly hopeless (heck, /vmunix
doesn't exist on a Linux box, let alone a Macintosh), but that's
something you get used to. To paraphrase Matthias Neeracher, MacPerl's
author, Perl tests are largely a test of whether you're running Unix.
The same problem occurs with mailto.pm, which will have to be rewritten
with something like MacSMTP, a Perl 4 package that does SMTP.
Otherwise, I'm very impressed. I used UserAgent.pm's useAlarm to turn off
the alarms, and I'm very happy to see that the Request's can be made to
retrieve to files (or to a subroutine, which will be very useful in
filtering Content-type text/* to Mac text files) rather than to $content .
With MacOS's lame memory management and only 14 Mb RAM on my Powerbook,
I've had to be careful with the sizes of http:'s I grab with libwww. Now
all I have to do is wait the few weeks until MacPerl 5 comes out to try
it all out.
Many thanks to the authors and contributors to lwp. I'm looking forward to
using it.
---
--------
Paul J. Schinder
NASA Goddard Space Flight Center,
Code 693, Greenbelt, MD 20771 USA
schinder@pjstoaster.pg.md.us