Re: Comments on LWP from a Mac user

Gisle Aas (aas@oslonett.no)
Mon, 07 Aug 1995 09:02:59 +0200 

> 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.

I would not mind having a portable library if somebody contributes solutions 
and testing on non-Unix platforms.

> 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";.  

These ones should be easy to fix.

>                                                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.

Does fastcwd() return a colon-separated path in MacPerl?

We could set it up such that URI::URL::file->fullpath returns a path that is 
suitable for the local OS type, so that we can assume that we can try to open 
the file directly.

How would you test if you are running under MacPerl at runtime?  Something 
like:

    use Config;
    if ($Config{'osname'} eq 'Mac') ...

or just if ('/r' eq '/012') ...???


>                 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

If we could test OS at runtime we could set the code up to use the correct 
directory separator.  Perhaps we have the same kind of trouble with VMS?


> 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.

My plan is to base it on Mail::Send that tries hard to find a suitable way of 
sending mail.  It should then able be able to send mail by using SMTP 
directly, but I don't know if it will port to Mac easily.

We could easily have different versions of things like LWP::Protocols::mailto 
for different environments.  We just have to select the right module at 
install time.

--
Gisle Aas                               <aas@oslonett.no>
Oslonett AS                             http://www.oslonett.no/home/aas/