www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D web apps: cgi.d now supports scgi

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

some docs:
http://arsdnet.net/web.d/cgi.html
http://arsdnet.net/web.d/cgi.d.html

The file cgi.d in there is my base library for web apps.

Previously, it spoke regular CGI, FastCGI (with help
from a C lib) and HTTP (with help from the netman.d
and httpd.d files in that github).


Now, in addition to those options, it also speaks
SCGI - all by itself - and it can speak http without
needing helper modules.

The new embedded http server should work on all
platforms too, not just linux like the old one, but
I haven't tested it yet.


This finishes out all the major web app interfaces
that I'm aware of.


To use them, you write your app with a GenericMain
and always communicate through the Cgi object it
passes you.

===
import arsd.cgi;
void hello(Cgi cgi) {
     cgi.write("Hello, world! " ~ cgi.request("name") ~ "\n");
}
mixin GenericMain!hello;
===


And then compile:

dmd hello.d arsd/cgi.d # builds a CGI binary
dmd hello.d arsd/cgi.d -version=fastcgi # FastCGI. needs libfcgi 
C lib
dmd hello.d arsd/cgi.d -version=scgi # SCGI
dmd hello.d arsd/cgi.d -version=embedded_httpd # built-in http 
server


The API is the same with all four options.

With cgi or fastcgi, you put the binary where your web
server can run it.

With scgi and embedded_httpd, you run the binary. It
persists as an application server. On the command line,
you can say use the option "--port 5000" for example
to change the listening tcp port.

The default for httpd right now is 8085. The default
for scgi is 4000.



Well, I don't have much else to say, but since it
now does all four of the big interfaces easily,
I thought I'd say something here.

If you're interested in web programming with D,
this will lay the foundation for you.
Mar 24 2012
next sibling parent "Andrea Fontana" <nospam example.com> writes:
+1 for scgi support :)

On Sunday, 25 March 2012 at 04:43:07 UTC, Adam D. Ruppe wrote:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

 some docs:
 http://arsdnet.net/web.d/cgi.html
 http://arsdnet.net/web.d/cgi.d.html

 The file cgi.d in there is my base library for web apps.

 Previously, it spoke regular CGI, FastCGI (with help
 from a C lib) and HTTP (with help from the netman.d
 and httpd.d files in that github).


 Now, in addition to those options, it also speaks
 SCGI - all by itself - and it can speak http without
 needing helper modules.

 The new embedded http server should work on all
 platforms too, not just linux like the old one, but
 I haven't tested it yet.


 This finishes out all the major web app interfaces
 that I'm aware of.


 To use them, you write your app with a GenericMain
 and always communicate through the Cgi object it
 passes you.

 ===
 import arsd.cgi;
 void hello(Cgi cgi) {
     cgi.write("Hello, world! " ~ cgi.request("name") ~ "\n");
 }
 mixin GenericMain!hello;
 ===


 And then compile:

 dmd hello.d arsd/cgi.d # builds a CGI binary
 dmd hello.d arsd/cgi.d -version=fastcgi # FastCGI. needs 
 libfcgi C lib
 dmd hello.d arsd/cgi.d -version=scgi # SCGI
 dmd hello.d arsd/cgi.d -version=embedded_httpd # built-in http 
 server


 The API is the same with all four options.

 With cgi or fastcgi, you put the binary where your web
 server can run it.

 With scgi and embedded_httpd, you run the binary. It
 persists as an application server. On the command line,
 you can say use the option "--port 5000" for example
 to change the listening tcp port.

 The default for httpd right now is 8085. The default
 for scgi is 4000.



 Well, I don't have much else to say, but since it
 now does all four of the big interfaces easily,
 I thought I'd say something here.

 If you're interested in web programming with D,
 this will lay the foundation for you.

Mar 25 2012
prev sibling next sibling parent "dnewbie" <run3 myopera.com> writes:
Thanks for doing this (and the other misc stuff)
I wonder how can I generate unique, non predictable session ids.
Mar 25 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 25 March 2012 at 19:14:32 UTC, dnewbie wrote:
 I wonder how can I generate unique, non predictable session ids.

In web.d, there's a Session class that generates them with std.random.uniform. I suspect this isn't the best possible, but it's worked pretty well so far. The session class also uses a file to store persistent string key/value data.
Mar 25 2012
prev sibling next sibling parent "dnewbie" <run3 myopera.com> writes:
On Sunday, 25 March 2012 at 19:22:02 UTC, Adam D. Ruppe wrote:
 On Sunday, 25 March 2012 at 19:14:32 UTC, dnewbie wrote:
 I wonder how can I generate unique, non predictable session 
 ids.

In web.d, there's a Session class that generates them with std.random.uniform. I suspect this isn't the best possible, but it's worked pretty well so far. The session class also uses a file to store persistent string key/value data.

This is what I was looking for. Rock'n'roll!!
Mar 25 2012
prev sibling next sibling parent "dnewbie" <run3 myopera.com> writes:
I can't compile web.d

Notice: As of Phobos 2.055, std.date and std.dateparse have been 
deprecated. They will be removed in February 2012. Please use 
std.datetime instead.
arsd\web.d(2671): Error: function std.date.dateFromTime is 
deprecated
arsd\web.d(2672): Error: function std.date.yearFromTime is 
deprecated
arsd\web.d(2673): Error: function std.date.monthFromTime is 
deprecated
Mar 25 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 26 March 2012 08:37, dnewbie <run3 myopera.com> wrote:
 On Sunday, 25 March 2012 at 19:22:02 UTC, Adam D. Ruppe wrote:
 On Sunday, 25 March 2012 at 19:14:32 UTC, dnewbie wrote:
 I wonder how can I generate unique, non predictable session ids.

In web.d, there's a Session class that generates them with std.random.uniform. I suspect this isn't the best possible, but it's worked pretty well so far. The session class also uses a file to store persistent string key/value data.

This is what I was looking for. Rock'n'roll!!

Slightly off-topic, but what is your policy of derivative works Adam? So if I built something similar off your work, but gave you credit, and pushed any changes/bugfixes/improvements back to you, that would be ok? Basically, if I build my own libraries off yours, I assume that fine. Since I don't really want to repeat all the work you have done already. -- James Miller
Mar 25 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 25 March 2012 at 20:12:16 UTC, dnewbie wrote:
 I can't compile web.d

Oh yeah, Phobos loves removing perfectly good functionality. Just open the file and comment out that function. Make it simply: string date(string replacement, string[], in Element, string) { /* auto date = to!long(replacement); import std.date; auto day = dateFromTime(date); auto year = yearFromTime(date); auto month = monthNames[monthFromTime(date)]; replacement = format("%s %d, %d", month, day, year); */ return replacement; } and it will be fine. That function isn't really needed, it is just one of the template formatting options. Eventually, I'll port it to the monster that is std.datetime but I'm not in a big rush.
Mar 25 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 25 March 2012 at 20:18:51 UTC, James Miller wrote:
 Slightly off-topic, but what is your policy of derivative works 
 Adam?

I don't really care; you can do whatever you want with it. It is generally Boost license like Phobos (I put it at the bottom of the files since licenses annoy me) which is pretty permissive.
 and pushed any changes/bugfixes/improvements back to you, that 
 would be ok?

Yea. And if your new functions might be generally useful or mix right it, feel free to do a pull request for that too. It is a "misc stuff" repo :P
Mar 25 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 25 March 2012 at 19:37:12 UTC, dnewbie wrote:
 This is what I was looking for. Rock'n'roll!!

BTW I tried to keep Session simple, and there's some doc comments, but the basic usage is as simple as: // loads the session, or creates a new one if needed auto session = new Session(cgi); // it does NOT auto save, so you want to call // session.commit() when you're done. // scope(exit) makes that easy. scope(exit) session.commit(); bool checkLogin() { if(session.hasKey("user_id")) { // see if a key is set // the user is logged in string uid = session.user_id; // can get data via opDispatch return true; } return false; } void logout() { session.invalidate(); // clears and deletes the session } void login() { session.invalidate(); // kill the guest session session.user_id = uid; // save the user id in the session via opDispatch } If you use web.d's FancyMain, it creates a session for you, so your ApiProvider class already has a session member you can tap right into. import web.d; class MySite : ApiProvider { void something () { session.cool = "something"; // works } } mixin FancyMain!MySite;
Mar 25 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 26 March 2012 09:28, Adam D. Ruppe <destructionator gmail.com> wrote:
 I don't really care; you can do whatever you want with it.

I figured, but its nice to ask first :D. -- James Miller
Mar 25 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 25 March 2012 at 19:22:02 UTC, Adam D. Ruppe wrote:
 On Sunday, 25 March 2012 at 19:14:32 UTC, dnewbie wrote:
 I wonder how can I generate unique, non predictable session 
 ids.

In web.d, there's a Session class that generates them with std.random.uniform. I suspect this isn't the best possible, but it's worked pretty well so far. The session class also uses a file to store persistent string key/value data.

While using std.random is probably good enough for most sites, it's definitely worth keeping in mind that these session IDs are far from non-predictable. Generally, a secure random number generator is used instead, but Phobos lacks something like this.
Mar 25 2012
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
Adam D. Ruppe wrote:

 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-

 
 some docs:
 http://arsdnet.net/web.d/cgi.html
 http://arsdnet.net/web.d/cgi.d.html
 
 The file cgi.d in there is my base library for web apps.
 
 Previously, it spoke regular CGI, FastCGI (with help
 from a C lib) and HTTP (with help from the netman.d
 and httpd.d files in that github).
 
 
 Now, in addition to those options, it also speaks
 SCGI - all by itself - and it can speak http without
 needing helper modules.
 
 The new embedded http server should work on all
 platforms too, not just linux like the old one, but
 I haven't tested it yet.
 
 
 This finishes out all the major web app interfaces
 that I'm aware of.
 
 
 To use them, you write your app with a GenericMain
 and always communicate through the Cgi object it
 passes you.
 
 ===
 import arsd.cgi;
 void hello(Cgi cgi) {
      cgi.write("Hello, world! " ~ cgi.request("name") ~ "\n");
 }
 mixin GenericMain!hello;
 ===
 
 
 And then compile:
 
 dmd hello.d arsd/cgi.d # builds a CGI binary
 dmd hello.d arsd/cgi.d -version=fastcgi # FastCGI. needs libfcgi
 C lib
 dmd hello.d arsd/cgi.d -version=scgi # SCGI
 dmd hello.d arsd/cgi.d -version=embedded_httpd # built-in http
 server
 
 
 The API is the same with all four options.
 
 With cgi or fastcgi, you put the binary where your web
 server can run it.
 
 With scgi and embedded_httpd, you run the binary. It
 persists as an application server. On the command line,
 you can say use the option "--port 5000" for example
 to change the listening tcp port.
 
 The default for httpd right now is 8085. The default
 for scgi is 4000.
 
 
 
 Well, I don't have much else to say, but since it
 now does all four of the big interfaces easily,
 I thought I'd say something here.
 
 If you're interested in web programming with D,
 this will lay the foundation for you.

Amazing! Well-done Adam!
Mar 26 2012
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/25/12 12:43 PM, Adam D. Ruppe wrote:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff


 some docs:
 http://arsdnet.net/web.d/cgi.html
 http://arsdnet.net/web.d/cgi.d.html

Very nice! I'd recommend moving those two html pages to github's wiki, or some other wiki. If people start using your library they can contribute with explanations, example usages, etc. I also see many empty or short sections in those documents, which again I think is asking for a wiki. I'm also not sure about the format you provide for getting the code: many unrelated modules all in a single directory. If I want to start developing web apps using your framework I need to clone that repo, think which files to import, etc. If all the related web stuff were in a separate repository, I could just clone it, import an "all" file and that's it. (well, the last point isn't really your fault, something like Jacob Carlborg's Orbit is really needed to make D code universally accessible and searchable)
Mar 26 2012
parent Ary Manzana <ary esperanto.org.ar> writes:
On 3/27/12 10:25 AM, Adam D. Ruppe wrote:
 On Tuesday, 27 March 2012 at 00:53:45 UTC, Ary Manzana wrote:
 I'd recommend moving those two html pages to github's wiki, or some
 other wiki. If people start using your library they can contribute
 with explanations, example usages, etc.

Yeah, I started that for the dom.d but haven't gotten around to much yet.

(snip)
 (well, the last point isn't really your fault, something like Jacob
 Carlborg's Orbit is really needed to make D code universally
 accessible and searchable)

I could add my build.d up there too... which offers auto downloading and module adding, but it is kinda slow (it runs dmd twice).

How slow is it comparing it to a developer doing it manually? :-)
Mar 26 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 27 March 2012 at 00:53:45 UTC, Ary Manzana wrote:
 I'd recommend moving those two html pages to github's wiki, or 
 some other wiki. If people start using your library they can 
 contribute with explanations, example usages, etc.

Yeah, I started that for the dom.d but haven't gotten around to much yet.
 I also see many empty or short sections in those documents, 
 which again I think is asking for a wiki.

or for me to finally finish writing it :)
 I'm also not sure about the format you provide for getting the 
 code: many unrelated modules all in a single directory.

They aren't really unrelated; most of them worth together to some extent. If you grab web.d for instance, you also need to grab cgi.d, dom.d, characterencodings.d, sha.d, html.d, and color.d. If you are doing a database site, you can add database.d and mysql.d (or postgres.d or sqlite.d) to the list. curl.d and csv.d are nice for working with external sources of data. rtud.d depends on cgi.d for pushing real time updates. So, all of it really does go together, but you don't necessarily need all of it. dom.d and characterencodings.d can be used independently. cgi.d has no external dependencies. etc. They are independent, but complementary.
 (well, the last point isn't really your fault, something like 
 Jacob Carlborg's Orbit is really needed to make D code 
 universally accessible and searchable)

I could add my build.d up there too... which offers auto downloading and module adding, but it is kinda slow (it runs dmd twice).
Mar 26 2012