David Grove wrote:
> 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.
David, I _think_ your case would be solved by the Penguin module, which adds
security. I don't really know if it's possible to debug with it. The
difference I see is that you're trying to use remote scripts, while here we
discuss the background autoloading of _modules_ that would be used by a
script that a user is trying to run.
I aggree that this too much auto no-control stuff is bad, but I think at
least we could provide a way to explicitly include the dependencies and
download/install instructions of modules of a script/module together with
it, and provide a utility (maybe external, user triggered) that would
download and install everything the user needs to actually run the script.
I say for myself, at least, that getting modules from CPAN and building them
is a burden on me, and when I download some nifty tool from Internet for a
quick job, I don't want to go in the complexities of MakeMaker, Makefiles,
not to mention compilers, which I don't have access on Win32 (yeah, I have
Cygwin, but I never compiled Perl with it...). I think easy
access/downloading/building of external modules is a must to make Perl more
popular.
- Branden
