|There's more than one way to do things|
Re: The Future - Shipping Applications Written in Perlby tinman (Curate)
|on Jun 20, 2001 at 01:39 UTC||Need Help??|
Coming from a decidedly java-centric background, and working with people who do not use Perl regularly, I have also felt the need for this.. I'll just note a few thoughts I've had on the topic, a full blown solution, unfortunately, isn't something I can offer... any way you ship an application, there are bound to be tradeoffs..
The first, much maligned method is compilation as an executable.. as merlyn has pointed out, it doesn't promote reuse of the Perl interpreter (essentially, an interpreter is bundled with each executable), and executable compilation (at least on Win32, where I use it) is still a young technology.. You need to explicitly include modules sometimes, sometimes the darned thing just doesn't work anyway... with that being said, its still great way to ship applications (yes, all 2+ mb of it).. No one needs to know or care about which language the app is written in, and excluding any fatal errors, no one will ever know (on fatal errors, you get a PERL2EXE prefixed error message)...
Unfortunately, a Perl interpreter is not standard on either MacOS or Win32.. this is where Java might have an advantage, because a valid JRE is usually installed with a browser and at a pinch, a Java app can run on that JRE (it usually dies horribly, but an option with a small chance of working is better than no option at all :o). Visual Basic, I believe is similarly blessed, at least on Win32
Other methods.. well, I've discussed bundling in the form of a question, some time back.. and I think its a valid method to try.. especially for modules which are not part of the standard distribution.. a reasonable thing to do is to use lib and have the module as part of the source itself.. This still doesn't solve the problem of the interpreter on the machine though..
I don't know about the feasibility of the next method, but Python and Java both have some form of it.. essentially, bytecode compile the source, make a bytecode image (with all the necessary module code compiled in) and ship with a scaled down version of the interpreter which just executes code (it doesn't need to load, locate or compile any code, just execute it).. I don't know if its practical, really, or how much of a saving this will be... but its something that could be borrowed from the other languages that use this method...
Umm.. the final solution of course, is an automatic installer.. if there are any Java people out there, Webstart is one tool that is really good.. it automatically installs and runs an application, so that distribution is taken care of.... this however, requires a net connection and that is not always feasible..
Oh, and the absolute final solution (I promise :o): download the appropriate Perl binary or compile from source, and start maintaining a Perl installation on the client machines.. guaranteed to work, and with things like CPAN.pm, PPM and other install managers, the administrative hassles can only lessen...
Random pie in the sky idea: Have a Perl installation on a server, and have clients contact this known server for compilation.. sort of like RPC or SOAP, if you like.. (please don't flame me about the security implications, I know, I know! :o) at least, you won't need to install Perl on all the machines...
Well.. apologies if you fell asleep during this rambling reply :o) wake up now, and go get yourself a Perl installation if you don't have one already.. that seems to be the best solution for now...