Dan Sugalski <[EMAIL PROTECTED]> wrote:

 > At 02:17 PM 2/5/2001 -0200, Branden wrote:
 > > > I think that, if you want this behavior, a module that implements
it
 > > > would be just fine.  (Why muck with "use"?)  To use a module name
 > > > that seems like it could fit this purpose:
 > > >
 > > > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
 > > >              { Baz => 'ftp://my.local.domain/perl-modules/Baz',
 > VERSION =>
 > >2 };
 > >
 > >Very good idea indeed!!! Append the wishlist to add this module to
perl6's
 > >standard library!!!
 >
 > Very *bad* idea. It sounds nice, but using a remote module without any
 > sort
 > of control is just begging for trouble.
 >
 > This would make your average unpatched Microsoft product look
impregnably
 > secure by comparison, and I can guarantee you it'd be the first thing
I'd
 > disable when building perl.

Please excuse me if I'm not up to date in this thread. I'm going on this
posting only.

Although I'd agree with you about the security, Dan, this kind of remote
processing would, I think, be useful in my case as well, although at a
minimum it should be a non-default option. Currently, I'm doing some of
this by grabbing remote code and running it through exec(), but that's not
debuggable. I administer IS for offices in three continents and several
locations in the US, and prefer to have parts of my code distributed in
this way. In fact, one of my main scripts is basically an empty tk root
window (with a menu) that gets its contents remotely in this way. Of
course, those contents travel compressed and encrypted.

The other option for me would be to be able to debug what's inside an
eval(), which IIRC we've already shot down.

p


Reply via email to