ActiveState’s Perl distribution includes PerlScript, so yes, it is “possible.” And if your app is being written for an intranet, using PerlScript might even be “feasible.” On the open web, however, it would be a stupid idea.
And no, you can’t pass objects between server and client that way either.
However, have you seen JSON? There’s a module for it, too.
Makeshifts last the longest.
| [reply] |
I think that yes, but, I am not sure that it can be optimal resolution - many questions have to be answered to explain your requirements... For instance, have you some GUI on clients, which have to be integrated with scripting perl? Which of client's OS? Have you some security requirements on client stations (sandbox)? What about updating/upgrading proprietary perl modules?
So, imho, I think that general sharing of perl objects is impossible, but if you use your own objects only, you can implement some serialize/restore methods (or, hopefully use Data::Dumper), which can help.
I have some experience with server-side Javascript (SpiderMonkey by Mozilla), and I should recommend this language as good solution, because this lang was developed as scripting language, and it is possible to integrate it into applications, naturally written in other languages. I participed on javascript representations of perl-objects, and on perl representations of javascript-objects, too. (Horrible work through SpiderMonkey C-API and perl XS, memory leaks, but good challenge :>) | [reply] |
I'd recommend just using JavaScript for client side logic and Perl for server side logic.
As far as I know, you can't technically use Perl on the client side anyhow. Anything you find to that regard will most likely just translate your Perl to a client side scripting language like JavaScript.
So, you'll be using JavaScript (or possibly VBScript) in the long run anyway. | [reply] |