Why Win32::Internet (Re: Managing Architecture-Dependant Perl Modules in an Object-Oriented Hierarchy)

I'd much rather have the OS-dependent stuff in a module than repeated in every script that needs to portably do what is provided by several OS-specific modules! Modules are the best place for the "ugly" code that is sometimes needed.

But, Net::FTP is already portable so there is no need to ever use Win32::Internet for doing FTP from Perl. Info about advantages of Win32::Internet over Net::FTP are welcome. I'm curious if there are any.

- tye (but my friends call me "Tye")

Comment on Why Win32::Internet (Re: Managing Architecture-Dependant Perl Modules in an Object-Oriented Hierarchy)

Replies are listed 'Best First'.
RE (tilly) 1: Why Win32::Internet (Re: Managing Architecture-Dependant Perl Modules in an Object-Oriented Hierarchy) by tilly (Archbishop) on Sep 22, 2000 at 06:29 UTC
I found an advantage to Win32::Internet over standard portable alternatives. I had problems proxying https connections, but on Windows if I just used Win32::Internet it worked like a charm. Since I just needed a quick answer that ran on someone's desktop, I left it at that rather than worrying about SSLeay, etc (which really was not cooperating). Never tried to track down the proxying problem since I never had to, but if someone else has I wouldn't mind knowing what the issue was...	[reply]

Replies are listed 'Best First'.

RE (tilly) 1: Why Win32::Internet (Re: Managing Architecture-Dependant Perl Modules in an Object-Oriented Hierarchy)
by tilly (Archbishop) on Sep 22, 2000 at 06:29 UTC

I had problems proxying https connections, but on Windows if I just used Win32::Internet it worked like a charm. Since I just needed a quick answer that ran on someone's desktop, I left it at that rather than worrying about SSLeay, etc (which really was not cooperating).

Never tried to track down the proxying problem since I never had to, but if someone else has I wouldn't mind knowing what the issue was...

[reply]