Re: Comments on LWP from a Mac user
Paul Schinder (schinder@pjstoaster.pg.md.us)
Mon, 07 Aug 95 21:38:43 -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.
}
} I would not mind having a portable library if somebody contributes solutions
} and testing on non-Unix platforms.
I'd be glad to write the routines that need to be done and to test it,
but as I said, a MacPerl 5 that I can run on my Mac is at least a few
weeks away. What I have working in my Perl 4 libwww port should work,
I'd just have to bulletproof it. What I have now is what I'd resonably
expect to have to handle, and I know it won't handle all possible paths
it's handed.
[\r\n issue]
}
} These ones should be easy to fix.
Generally I just change \r\n and \r?\n (when you test a pattern) to
\015\012 and \015?\012. I work under the assumption that when
everything is done I'm going to pass whatever comes back from lwp
that's Content-type: text/* through a s/\012/\015/g, so I don't mind
whether Unix or Mac text comes back.
}
} > 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?
I just checked the MacPerl 4 version, and it doesn't work at all. (The
routine supplied is identical to the Unix version, so chdir(".") and
chdir("..") fail, and it returns /. I don't know why it's there at
all.) If there is a MacPerl 5 version, it will either fail or give a
valid Mac pathname (like, for example `pwd` does; it's one of the few
`commands` that work and it's actually handled internally). I suppose
neither is desirable for the way it's used in URI::URL::newlocal.
}
} 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.
That's a possibility.
}
} 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') ...???
At the moment, in MacPerl 4 there's a package MacPerl, available
implicitly in every script, that includes, among other things,
$MacPerl'Version, so you generally test $MacPerl'Version to see whether
or not you're in MacPerl. I imagine there will be a $MacPerl::Version
in MacPerl 5. There will probably also be a $Config{'osname'}
(probably it will be "MacOS"), but I can't be sure yet. But do you
really want a long string of if statements, one for every architecture
supported? It seems to me that the number of places that lwp and URL
access the local file system are limited, and one replacable module
should be enough to take care of what's needed. The network parts
should work the same everywhere provided one is careful about the
\015\012 issue.
[deleted]
} > < #
} > < # 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?
Probably (it's been a long time; isn't it something like
DISK:[DIR1.DIR2.DIR3.FILE] ?) That's why this should probably be
written something like
$_ = &localdir($_) if -d &localpath($path,$_);
}
}
} > 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.
Sockets work just fine in MacPerl (I do most of my ftp:, http:, and
gopher: in MacPerl), so it should port with no problem. I've always
thought it safest to use the GUSI (Grand Unified Sockets Interface)
that Matthias provides rather than just let the socket calls happen, so
I don't know for sure whether they'd work unchanged, but it's no big
deal changing them, and this can be isolated in Sockets.pm. The real
problem would be if you hardcoded localhost in as the SMTP host. You
should let it be settable, maybe through $ENV ($ENV{'SMTPHOST'},
maybe). A lot of Macs, mine included, are on the net intermittently
via PPP/SLIP rather than 24 hours on an Ethernet, and I run UUPC as my
MTA rather than an SMTP server. (There is an SMTP server for the Mac,
but neither system("") or | work under MacPerl anyway, so it would be
difficult to portably use SMTP through the server). I'd use my Sun
workstation running Berkeley sendmail at work for my SMTPHOST, and
other's would probably use their Internet providers SMTP server.
}
} 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.
Right. The trick is to isolate those things that need to be changed
per archtecture, so that porting LWP is a matter of changing a couple
of modules rather than going through the entire library line by line
looking for gotchas. This is one module that might need to be
architecture dependent (maybe not if the SMTP can be done entirely in
Perl), and interacting with the local file system is definitely
another.
Thanks for the reply.
}
} --
} Gisle Aas <aas@oslonett.no>
} Oslonett AS http://www.oslonett.no/home/aas/
}
}
}
---
--------
Paul J. Schinder
NASA Goddard Space Flight Center,
Code 693, Greenbelt, MD 20771 USA
schinder@pjstoaster.pg.md.us