CGI example needed

[Tim Johnson]

I've been a CGI programmer for 16 years. I have used python for the
last 9. I currently use javascript for client-side programming. I am
interested in using node.js for server-side programming.

I've done a little googling on CGI interfaces for node, but I am
finding *too* much information.

I am including an untested pseudo-code based on python. With that as
a reference, I would welcome some javascript code which would work
similarly:
code follows
##################################################################
#!/usr/bin/python
import cgilib ## my cgi module
import mvcLoader as load ## handles importing controller modules
## script loader.py (the executable 'parent' module)
## is the post action for a form which
## accepts an email address and a password as input fields named
## "email" and "password".
## loader.py has a virtual document path that has as path part 0
## a key for the controller that will be `import'ed by the parent module.
## the post action might look like this:
## "http://localhost/cgi-bin/loader.py/auth"
if __name__=="__main__":
## instantiate the cgi object and in doing so,
## process the CGI environment
cgi = cgilib.Cgi()
## print the mime-type header
cgi.header('text')
## Retrieve the values POSTed for 'email' and 'password'
user = cgi["email"]
pwd = cgi["password"]
## Retrieve the key for the controller module which will then be imported
## by the load.controller() method
controller_key = cgi[0]
controller = load.controller(cgi[0])
## And the rest of the work happens below
## in the imported controller module
controller.process(user,pwd)
##################################################################
The intent and mechanics of my mvcLoad module should not be relevant
to this dicussion. What is relevant is allegories to
cgi[keyname]
and
cgi[virtual_document_path_index]

I hope that the example makes my question clear. I don't expect
anyone to "roll their own" tutorial, but URLs to discussions
on similar node interfaces would be most helpful.

TIA
--
Tim
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com

[Dan Milon]

You wouldn't use node as a cgi script (at least for the web part).
Technically you can, but you would lose all the benefits
(async/nonblocking io) since you let apache or any http server for the
matter enforce the concurrency model. Afaik, the cgi server will pull up
node processes for each request, which is overkill (startup times) or
pool them but things will get complex.

As it concerns network/http related scripts, its a big no no, unless you
cant replace the http server in your stack, and really need to use node
(which is a silly case)
If you have to use cgi, i suggest you keep using php/python.

Why dont you use node as the server also? (not only processing requests)

[Arunoda Susiripala]

You need this - http://expressjs.com

Read the guide.

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[Nathan Rajlich]

And if you want the opposite (using Node to invoke and serve CGI files), then you can check out node-cgi: https://github.com/TooTallNate/node-cgi

nodejs+un...@googlegroups.com

[Tim Johnson]

* Dan Milon <danm...@gmail.com> [120708 10:27]:

> You wouldn't use node as a cgi script (at least for the web part).
> Technically you can, but you would lose all the benefits
> (async/nonblocking io) since you let apache or any http server for the
> matter enforce the concurrency model. Afaik, the cgi server will pull up
> node processes for each request, which is overkill (startup times) or
> pool them but things will get complex.
>
> As it concerns network/http related scripts, its a big no no, unless you
> cant replace the http server in your stack, and really need to use node
> (which is a silly case)
> If you have to use cgi, i suggest you keep using php/python.

:) python is not PHP ... and my question was pretty much
rhetorical. I don't know much about the origin of node, I ended up
with it in the process of getting csslint installed - so it is all
new to me.

> Why dont you use node as the server also? (not only processing requests)

Ah! So node was developed to as a 'serving' tool as opposed to a
'scripting' tool?

thanks for the reply

[Dan Milon]

Yeah, You should read up nodejs.org & tutorials / blogs to learn more ;)

danmilon.

[Louis Santillan]

V8cgi might be more of what you need. (http://code.google.com/p/v8cgi/)

 -L

[hasanyasin]

I have worked with Python for 10+ years over Apache and rarely other platforms too. I have developed software over mod_python and mod_wsgi. I will try to shortly touch a few main differences between how we did things in Python using it with different platforms and what are the similarities and differences between those and the environment Node provides.

First of all, Node is not direct competition of Python. Everything is different from head to toe between two platforms.

There are many different implementations of Python interpreter today; but they all try to stick with the standard definition of the language. The standard interpreter cPython comes with a very rich standard library. In this standard library, there are modules to quickly develop a web server; but we rarely use those. Instead, we depend on other web servers like Apache or nginx to handle http. However, there are also web servers we now have access to which are really close to Node. One very famous of them is Tornado.

At Node's side, things are pretty different. First of all, JavaScript standard does not define a standard library like Python or many other languages do. This is not a shortness; but a different way of seeing the world.

Node is built on V8, a JavaScript interpreter. This way, Node provides something like python interpreter in regards to being an executable application to run scripts. The very same way you run python myscript.py, you run node myscript.js.

Node also has its own standard library of functions. It is nowhere close to having everything like Python standard library does. Again, this is not a lack of features, this is the way Node is meant to be. Instead of having a giant standard library, Node has a playful module system that provides extremely easy ways to build, pack and publicly share your libraries. Node simply prefers playing liberally instead of dictatorship.

As for the key point in your question, as a web development environment, what Node provides is almost the same as what Tornado provides. Web server is not a separate application. You have all low level http functionality as a library provided by Node. Don't get me wrong, I love Python, I still heavily use it for many things; but the http server module Node provides is a serious one unlike the one in Python standard library. Python's http library is meant to be used in development environments while Node's is designed and implemented for heavy-duty production servers. Again, if you take a look at how Tornado works, you will have a much quicker grasp on the mindset of Node's web development environment.

[Tim Johnson]

* hasanyasin <hasan...@gmail.com> [120709 07:11]:

>
> I have worked with Python for 10+ years over Apache and rarely other
> platforms too. I have developed software over mod_python and mod_wsgi. I
> will try to shortly touch a few main differences between how we did things
> in Python using it with different platforms and what are the similarities
> and differences between those and the environment Node provides.
>
> First of all, Node is not direct competition of Python. Everything is
> different from head to toe between two platforms.
>
> There are many different implementations of Python interpreter today; but
> they all try to stick with the standard definition of the language. The
> standard interpreter cPython comes with a very rich standard library. In
> this standard library, there are modules to quickly develop a web server;
> but we rarely use those. Instead, we depend on other web servers like
> Apache or nginx to handle http. However, there are also web servers we now
> have access to which are really close to Node. One very famous of them is
> Tornado.
>
> At Node's side, things are pretty different. First of all, JavaScript
> standard does not define a standard library like Python or many other
> languages do. This is not a shortness; but a different way of seeing the
> world.
>
> Node is built on V8, a JavaScript interpreter. This way, Node provides
> something like python interpreter in regards to being an executable
> application to run scripts. The very same way you run python myscript.py,
> you run node myscript.js.
>
> Node also has its own standard library of functions. It is nowhere close to

> having *everything* like Python standard library does. Again, this is not a

> lack of features, this is the way Node is meant to be. Instead of having a

> giant standard library, Node has a *playful* module system that provides

> extremely easy ways to build, pack and publicly share your libraries. Node
> simply prefers playing liberally instead of dictatorship.
>
> As for the key point in your question, as a web development environment,
> what Node provides is almost the same as what Tornado provides. Web server
> is not a separate application. You have all low level http functionality as
> a library provided by Node. Don't get me wrong, I love Python, I still
> heavily use it for many things; but the http server module Node provides is
> a serious one unlike the one in Python standard library. Python's http
> library is meant to be used in development environments while Node's is
> designed and implemented for heavy-duty production servers. Again, if you
> take a look at how Tornado works, you will have a much quicker grasp on the
> mindset of Node's web development environment.

Thanks very much for the thorough overview. I work in two
different types of platforms: 'One size fits all' server farm/web
hosters like Hostmonster and servers owned by clients. It is
likely that not all of the former types (Hostmonster et. al.)
would host node. Am I right?
cheers