I wrote this to solve a problem where I wanted to use a module on one machine that resides on another. The module goes like so:
package RemoteModule; =item Copyright 2004 John Drago <john.drago@e-commedia.com> This software is free software and may be distributed under the same terms as perl itself, so long as this copyright notice is included. Dependancies: LWP::UserAgent HTTP::Request::Common Synopsis: use RemoteModule "Crypt::RC4" => "http://search.cpan.org/src/S +IFUKURT/Crypt-RC4-2.02/RC4.pm"; use Crypt::RC4; my $crypted = RC4("secret password!!!", "Text to be encrypted!"); print "Encrypted: $crypted\n"; print "Decrypted: " . RC4( "secret password!!!", $crypted ); =cut use strict; my %urls = (); #======================================================== # #======================================================== sub import { my ($s) = shift; my ($class,$url) = @_; $urls{$class} = $url; }# end BEGIN{} #======================================================== # #======================================================== BEGIN { push @INC, sub { my ( $coderef, $filename ) = @_; $filename =~ s/\//::/g; $filename =~ s/\.pm$//; return undef unless defined $urls{$filename}; open my $fh, "perl " . " -MHTTP::Request::Common " . " -MLWP::UserAgent " . " -e \"print LWP::UserAgent->new->request( " . " GET '$urls{$filename}' " . " )->content\" | "; return $fh; }; }# end BEGIN 1;
Anyone come across a better method for achieving the same effect?

Replies are listed 'Best First'.
Re: Using Remote Modules over HTTP
by tilly (Archbishop) on Feb 21, 2004 at 03:25 UTC
    The::Net does something similar and chose to work similarly. Personally I would suggest a slightly different API. Rather than having to both set up the use and use the local module, I'd suggest having the import also do an immediate require and then do the import as well. (Thereby letting you remove the use command following.)
Re: Using Remote Modules over HTTP
by Mr. Muskrat (Canon) on Feb 21, 2004 at 01:52 UTC

    At first glance it doesn't look like it handles module dependency issues.

    Does it handle dependencies? If so, how?

Re: Using Remote Modules over HTTP
by fizbin (Chaplain) on Feb 22, 2004 at 05:04 UTC
    A few comments/suggestions:
    As someone else noted, this doesn't handle dependencies that occur in loading modules, and it would be nice if (e.g.) modules that Cram::MD4 depended on were loaded over the network, if necessary.

    One way to to this would be (assuming that we haven't been told explicitly how to load the asked-for module) to examine (caller(1))[3], strip the part following the last :: and see if the resulting package name is one that this module caused to be loaded over the network. If so, try to guess the pathname following the standard rules. Remember that you can touch the appropriate entry in the %INC hash to record little details about what was loaded over the network.

    Also, I am troubled by your invoking another perl interpreter. Among other things, I'd use $^X instead of "perl" - I occasionally work on machines where "perl" invokes perl 5.005, but "/qhds/bin/perl" invokes perl 5.6.1. However, it's possible to avoid a second perl interpreter - just do:

    use LWP::Simple; use IO::Scalar; my $modulecontent = get($urls{$filename}); if (!defined($modulecontent)) {return undef;} else {return new IO::Scalar \$modulecontent;}
    With sufficiently high versions of perl, you can even open a scalar for reading directly, exactly as you'd open a file, but for this usage the IO::Scalar code is simpler.
Re: Using Remote Modules over HTTP
by The Mad Hatter (Priest) on Feb 21, 2004 at 01:22 UTC
    Er, nevermind. I forgot that it needs a filehandle. You could save to a temporary file, but your method works just as well.

    Why do you spawn another Perl interpreter to fetch the code? Just load the modules yourself and do it all in your package. Spawning another perl process just uses up more overhead.

Re: Using Remote Modules over HTTP
by atcroft (Abbot) on Feb 21, 2004 at 01:09 UTC

    I may be mistaken, but isn't what you are trying to do the same problem that XML-RPC is intended to solve?

      And SOAP? No. XML-RPC allows you to create seperated rpc functions, but let's say you want to write a script where you have limited space or permissions (can't create dirs?), then this would work. I can't say it's uber secure, since it doesn't do md5 hashes or anything, but it is a solution. It does allow you to upgrade everywhere at once, providing you keep apache running :)

      I used to be a funny character, now I'm just 4 bits.