what script runs in a browser?

[chronodekar]

I have a Perl script that runs locally on my system. It aggregates data from some websites and outputs the result into a text file.

Is it possible for me to browser-ify this? In the sense, to host the script somewhere online and open the script-page in a browser window. Then, the browser should do the aggregation and give a dialog-box to save the text file locally.

I use different systems and not all of them have Perl installed. That's what led me to this. For that matter, if the above functionality can be achieved, I'm willing to learn another language as well.

Based on the little I know, HTML is for display-purposes, it won't command the browser to do anything else, so I can't use that. And PLEASE don't suggest running a 'web-service'. That's an over-kill. I want my browser to do this, not a remote server.

Puzzled,
-chronodekar

 

[BoberFett]

Why can't those other machines hit the machine that IS running Perl over HTTP? The local machine doesn't need Perl, it's only getting the output of the script. That's essentially what a web service is.

 

[Kr@n]

I would also suggest to create a web service (written in Perl). That would ensure you two things (+1 bonus) :

- All the aggregation mechanism is hosted on the server, allowing some easy data caching, easy maintenance (no compatibility headaches between browsers and such), easy throttling if needed, etc. - You won't have to rewrite the core of your code nor learn another language, nor specific browser tricks.

- As a bonus, your code logic wouldn't have to be "public", especially the list of websites you aggregate from (and more so if you're using credentials and such)


If you still want to code your mechanism browser-side, you'll have to do that in JavaScript (ES4 in well supported I think and quite powerful) and some XmlHttpRequest trickery (which is not as trivial as it could be) ... As for "saving" the file from HTML, it's not trivial to do either in JavaScript (without using the new File handling API that may help you there, but are not well supported). However, you can easily display the result in HTML and provide some helpers to copy/paste the text (in JavaScript)

 

[chronodekar]

Again, I am NOT looking for creating a web-service. That's really an OVERKILL. This is something I'll use sporadically and it just doesn't make sense to host it anywhere.

For having my work done browser-side, is Javascript the only option I've got? Any others? I can compromise on the file-saving requirement and try implementing something that needs to be copy-pasted.

-chronodekar

 

[degibson]

Your possible client-side scripts are, off the top of my head, JavaScript and VBScript. JS would probably be a better option. I'm not a JS proficient, however, so I don't have any specific pointers... sorry.

 

[Crusty]

It's for small things like this that I'm very glad my file server runs Linux.

 

[chronodekar]

I'm leaning towards Javascript right now. Does anyone know if it has good regex (regular expressions) support?

-chronodekar

 

[Cogman]

I'm leaning towards Javascript right now. Does anyone know if it has good regex (regular expressions) support?

-chronodekar

Javscript has some pretty good regex support built into it. However, be advised that javascript does not include any method of interacting with the OS (A good thing). In other words, there is no file I/O in javascript.

http://www.regular-expressions.info/javascriptexample.html

 

[sourceninja]

Although for the OP needs, he could just have javascript modify the dom to look like the text file he wants. Then he can just 'save that webpage'.

 

[BoberFett]

Again, I am NOT looking for creating a web-service. That's really an OVERKILL. This is something I'll use sporadically and it just doesn't make sense to host it anywhere.

For having my work done browser-side, is Javascript the only option I've got? Any others? I can compromise on the file-saving requirement and try implementing something that needs to be copy-pasted.

-chronodekar

If you already have the code written in Perl, overkill is when you rewrite it in Javascript for no good reason.

 

[Ken g6]

It aggregates data from some websites...

Uh, uh. You can't do that with xmlhttprequest. It's a security "feature". D:

You can do that in Greasemonkey, on Firefox only, with gm_xmlhttprequest.

 

[sourceninja]

Or as an extension with chrome/safari.

 

[jvroig]

In the sense, to host the script somewhere online and open the script-page in a browser window.

And PLEASE don't suggest running a 'web-service'. That's an over-kill. I want my browser to do this, not a remote server.

If you host the script "somewhere online" so that you can open the script-page (like www dot somewhere-online dot com / myperlscript.pl), what's stopping you from making it work in any browser in any machine? And why shouldn't we suggest a "web-service" (which you say is over-kill) when in essence that is what you've described (host a perl script somewhere so you can access it through the browser any time you want).

My confusion stems from those statements of yours in the OP that I've quoted.

If your first quoted statement is the question, then the answer is: "Yep, get free hosting that has perl support, and upload your perl script there. After that, you can access your perl script wherever you are, using any browser, any OS".

As for your second quoted statement, which evidently led you to the path of javascript, I have no idea why you want to do something browser-side. For one thing, do you want to carry the "program" around with you all the time, and run it through whatever browser is available to you at the moment? Because that's what it seems to me when you refuse to have your Perl script hosted because of 'over-kill' reasons. And that's the only thing possible, it seems to me, if your Perl script is not hosted anywhere online.

 

[chronodekar]

@jvroig,

I think I should make clear, when I say "web-service" I refer to something running on a remote server. i.e. the work is done remotely. But, when I say browser-based, I refer not just to display the data, but also to retrieve it from another source. Something similar to the way images can be linked.

When I said "host script online" - I was referring to the way one might open a text file in a browser. The server doesn't do any work beyond transmitting said file.

The suggestion of making an extension/greasemonkey script interests me. I think I'll take a look into it.

-chronodekar

 

[Kr@n]

As said before, if you do not want to make-it a web service (the sole reason I can think of would be bandwidth), then you are stuck with client-side JavaScript (I'm not sure VBScript runs in all browsers).

Alas, you will have to fight against browser inconsistencies (especially with XmlHttpRequest).

Uh, uh. You can't do that with xmlhttprequest. It's a security "feature". D:

You can do that in Greasemonkey, on Firefox only, with gm_xmlhttprequest.

I quite don't understand this statement. The script would be served by an online server and run in the browser (and would certainly not be run as a local JS or HTML file). Thus, the security limitations would not kick in. It's perfectly feasible to consume a remote web service or web page, even if it's not on the same domain (cross-domain requests are increasingly controlled, especially using third-party add-ons like NoScript, but it generally works), ... Am I completely off ?

 

[sourceninja]

If the script was being served via a online server, why not just use the perl you have and have it served by an online server? It would be faster to develop, easier to write, and just as portable as doing it all over in javascript.

 

[jvroig]

If the script was being served via a online server, why not just use the perl you have and have it served by an online server? It would be faster to develop, easier to write, and just as portable as doing it all over in javascript.

He does not want the server to do any processing.

I don't know why, maybe because the server where it is hosted doesn't support Perl, or maybe it is a shared hosting and his perl script will exceed CPU time limitations in the shared environment.