Hi,

What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or some sort of dynamic web base development?

How to compile a D code into dll to be used by apache or MS IIS?

How to also code digitally sign the DLL  that was compiled in D?

Matthew Ong

> What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or some sort of dynamic web base development?

I use D for web work by using the standard CGI interface and sometimes an embedded http server. It's the best thing I've ever used.

> How to also code digitally sign the DLL  that was compiled in D?

The same way you sign any other dll/exe.

Hi Adam,

Thanks again for the sharp pointed answer.
> What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or some sort of dynamic web base development?

>I use D for web work by using the standard CGI interface and >sometimes an embedded http server. It's the best thing I've ever used.
Could you share how or show an URL that provide sample code to do that in D?


> How to also code digitally sign the DLL  that was compiled in D?
The same way you sign any other dll/exe.
So we use external tool to do that and not a build in one??
In java, we use jarsigner with some keygen.

Please bear in mind I am new to D.

> Could you share how or show an URL that provide sample code to do that in D?

Check out my D api demo:

http://arsdnet.net/cgi-bin/apidemo/

Here's the source code (about 50 lines of D)
http://arsdnet.net/apidemo.d

And the HTML templates it uses: http://arsdnet.net/apidemo-document.html http://arsdnet.net/apidemo-javascript.html


The libraries it imports are available here

http://arsdnet.net/dcode/



That demo shows something relatively new I made to provide same source access to HTML and Javascript that uses D's reflection to auto-generate almost everything.


You can also do more traditional style web apps. Here's a gradient generator written in D:

http://arsdnet.net/cgi-bin/gradient?w=100&h=100&c1=ff0000&c2=00ff00&c4=ffff00&t=50

Source:
http://arsdnet.net/gradient.d

It uses my cgi.d from the dcode folder above. This code has a few features so it isn't the simplest demo, about 150 lines. It makes the png and sends it right out over the web.


Hello world with cgi.d looks like this:

import arsd.cgi;
void main() {
   auto cgi = new Cgi();
   cgi.write("Hello, world!");
   cgi.close();
}


In all my examples though, I used mixins for main functions instead of writing them directly because the mixin adds try/catch for exceptions and handles the create and close too. This would look like:

import arsd.cgi;
void run() { cgi.write("Hello, world!"); }
mixin GenericMain!run;


I also often use my D DOM library in web code too, which you see in the first example. That library is available in my folder too.

> So we use external tool to do that and not a build in one??

Yes, something like signtool.exe from Microsoft works for Windows programs.

Generally, if you can do it to a C++ program, you can do it to a D program too.

"Matthew Ong" <ongbp@yahoo.com> wrote in message news:iqgo17$2nqv$1@digitalmars.com...
> Hi Adam,
>
> Thanks again for the sharp pointed answer.
>> What is the counterpart in D for replacing JSP/ASP/JRuby on Rail or some sort of dynamic web base development?
>
>>I use D for web work by using the standard CGI interface and >sometimes an embedded http server. It's the best thing I've ever used.
> Could you share how or show an URL that provide sample code to do that in D?
>
>
>> How to also code digitally sign the DLL  that was compiled in D?
> The same way you sign any other dll/exe.
> So we use external tool to do that and not a build in one??
> In java, we use jarsigner with some keygen.
>
> Please bear in mind I am new to D.
>

Here's a basic "Hello world" CGI app in D:

// hellocgi.d
import std.conv;
import std.stdio;

void main()
{
    // Read in HTTP request headers
    string[] requestHeaders;
    while(true)
    {
        string line = readln();
        if(line.length <= 1)
            break;

        requestHeaders ~= line;
    }

    // Send response headers
    writeln("Status: 200 OK");
    writeln("Content-Type: text/html; charset=UTF-8");
    writeln();

    // Send content
    writeln("<b><i>Hello world</i></b>");
}

Compile with:
dmd hellocgi.d

And just stick the resulting "hellocgi.exe" (windows) or "hellocgi" (other) in whatever "cgi-bin"-capable directory you have on your server.

Everything else (such as fancy CGI libraries/frameworks like Adam's) can ultimately be built out of that basic idea.

Keep in mind though, that since D is natively compiled, you'll have to compile it on either the same OS and CPU architecture as your server, or an OS/CPU that's compatible with your server. (This would be true of C/C++ as well.)

I'm sure it's possible to make an ISAPI filter or Apache module in D, but I've never really done that in any langauge, and I haven't really dealt with DLLs much, so I wouldn't know how. But even as CGI, a web app in D is likely to still be much faster than one in, for instance, PHP or Ruby.

>    // Read in HTTP request headers

Actually, that's not quite right. The HTTP headers are sent as environment variables. stdin gives you the POST variables - with the encoding given in the HTTP_CONTENT_TYPE envvar iirc. (that's where the Content-Type http header is found).

The most common type is urlencoded, so it's just like parsing the query string. The other one I handle is multipart - the encoding for file upload forms.

Getting all that stuff out is the main benefit of a basic cgi library.. it's a bit of a pain to do yourself every time.

"Adam Ruppe" <destructionator@gmail.com> wrote in message news:iqhha9$17dp$1@digitalmars.com...
>>    // Read in HTTP request headers
>
> Actually, that's not quite right. The HTTP headers are sent as environment variables. stdin gives you the POST variables - with the encoding given in the HTTP_CONTENT_TYPE envvar iirc. (that's where the Content-Type http header is found).
>

Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...

> Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...

Speaking of brain rot, the first version of my cgi.d actually aimed to mimic PHP! Some stupid part of me actually started to *like* the superglobals for a while...

It had a static module constructor that built the arrays, and gave them global names like PHP does:

import cgi;

void main() {
     auto my_var = _POST["my_var"]; // works in D
}

It even simulated PHP's session_start() thing, though bugs in std.variant kept it from being particularly useful at the time. While std.variant is now fixed, I haven't had a need for sessions like that, so never updated that to the new module.



For some reason, I actually liked it at the time. But, it broke down when I decided to write my own little http server to avoid Apache bloat for an app. A shared, mutable global is obviously nasty there.

(I did stick with it for a while, but it got so complicated I
ditched the whole stupid thing and started over, writing the
new class based cgi.d. If you look at my code though, you'll see
a couple things that are very bizarre according to the CGI standard:
these are the things that let it work with the embedded httpd too.
It reads all headers itself and writes the raw protocol to sockets
instead of stdout when constructed that way. Thus, aside from the
constructor arguments, the rest of the client code looks the same,
so I can switch from embedded to apache/iis and back easily enough.
The functions being mixin GenericMain!() instead of main() is also
due to this, though the try/catch it provides is nice too.)


Anywho.

Another bad experience with PHP led me to make the get and post
vars in cgi.d completely immutable - something that leads to
some pain, since phobos and druntime don't care much for
immutable(char[])'s (instead opting to work with
immutable(char)[]'s. This has gotten worse in the new beta with
even the replace() function no longer working on the former! Ugh!)

But, some minor hacks here and there make it work, so yay.

And, unlike PHP, if some asshole decides to write $_POST["evil"] = $whatever; in his vile function, I won't have to deal with it later! Whoo hoo!

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:iqhkdn$1co1$1@digitalmars.com...
>> Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...
>
> Speaking of brain rot, the first version of my cgi.d actually aimed to mimic PHP! Some stupid part of me actually started to *like* the superglobals for a while...
>

Heh. Well they are at least convenient. I'm sure that's probably why PHP did it in the first place.

> It had a static module constructor that built the arrays, and gave them global names like PHP does:
>
> import cgi;
>
> void main() {
>     auto my_var = _POST["my_var"]; // works in D
> }
>
> It even simulated PHP's session_start() thing, though bugs in std.variant kept it from being particularly useful at the time. While std.variant is now fixed, I haven't had a need for sessions like that, so never updated that to the new module.
>

I don't know how yours works, but PHP's session system has a number a pains. The whole way it handles session timeouts is just bizarre, and the fact that it's even possible for the sysadmin to enable session.auto_start has caused me big headaches.

Actually, that get's into one of the big things I hate about PHP: there's far too much it allows sysadmins to fuck with. And it's not always possible for the programmer to override dumb php.ini settings. As a result, even a single specific point release of PHP is essentially 5 million different languages, depending what server you're on and your sysadmin's day-to-day whims. And a lot of the settings are just stupid features that never should have been put in in the first place (granted, those ones tend to become deprocated, but by then the damage is already done).

Which reminds me of the PHP4->PHP5 debacle. I can certainly appreciate the occasional need for changes that break backwards-compatibility (especially as a D user), so I don't have a problem per se with the fact that PHP5 broke backwards compatibility (although it's not like compatibility in PHP has ever been anything but a joke). But there are so many ways it would have been so trivial to avoid the problems it caused. Probably the simplest and most obvious would be a decree "Scripts targeting PHP5 and up must end with the extension .php5, otherwise it will either refuse to run or get sent to a PHP4 installation if available." Or instead of the extension, require the first line to be "<?php PHP5...", etc. So many easy ways to avoid the problems they had. And that's all just off the top of my head. But PHP's primary design principle seems to be "Be sloppy whenever possible."

Of course, D2 broke backards compatibility with D1 and doesn't have anything like what I suggested above for PHP5. But it works for D because the language exists completely on the development side, not on the server side like PHP.

>
> For some reason, I actually liked it at the time. But, it broke down when I decided to write my own little http server to avoid Apache bloat for an app.

Cool :)

It's amazing how simple a basic http server is. Yea, there's some details and gotchas to be careful of if you're really trying to follow the HTTP1.1 spec properly (which is probably a good idea anyway). But even still, someone who's never written a server would probably think it would need to be some major Apache-level undertaking. That's what I originally thought. But unless you're really going for super-flexibility/configurability/bells-and-whistles, etc., you really don't need 99% of that, and it actually ends up being pretty simple.

...Unless you want to run it on a shared web host. Then you're just plain shit-out-of-luck ;)

> A shared, mutable global is obviously
> nasty there.
>
> (I did stick with it for a while, but it got so complicated I
> ditched the whole stupid thing and started over, writing the
> new class based cgi.d. If you look at my code though, you'll see
> a couple things that are very bizarre according to the CGI standard:
> these are the things that let it work with the embedded httpd too.
> It reads all headers itself and writes the raw protocol to sockets
> instead of stdout when constructed that way. Thus, aside from the
> constructor arguments, the rest of the client code looks the same,
> so I can switch from embedded to apache/iis and back easily enough.

That's pretty cool.

> The functions being mixin GenericMain!() instead of main() is also
> due to this, though the try/catch it provides is nice too.)
>
>
> Anywho.
>
> Another bad experience with PHP led me to make the get and post
> vars in cgi.d completely immutable - something that leads to
> some pain, since phobos and druntime don't care much for
> immutable(char[])'s (instead opting to work with
> immutable(char)[]'s. This has gotten worse in the new beta with
> even the replace() function no longer working on the former! Ugh!)
>
> But, some minor hacks here and there make it work, so yay.
>
> And, unlike PHP, if some asshole decides to write $_POST["evil"] = $whatever; in his vile function, I won't have to deal with it later! Whoo hoo!

Yea, D kicks the snot out of PHP in so many ways. It's so unfortunate though that shared web hosts have SOOO much better support for PHP than native-compiled CGI. I suppose one could argue that's for security and reliability reasons, but PHP's known for being terrible in those areas, too. *shrug* Just a popularity thing I guess...It annoys me to no end that the computer world has become every bit as trend-driven as the high-fasion industry...I guess that's what happens when you let middle managers in on things.

On 2011-05-12 16:45, Adam Ruppe wrote:
>> Could you share how or show an URL that provide sample code to do
>> that in D?
>
> Check out my D api demo:
>
> http://arsdnet.net/cgi-bin/apidemo/
>
> Here's the source code (about 50 lines of D)
> http://arsdnet.net/apidemo.d
>
> And the HTML templates it uses:
> http://arsdnet.net/apidemo-document.html
> http://arsdnet.net/apidemo-javascript.html
>
>
> The libraries it imports are available here
>
> http://arsdnet.net/dcode/

How is it working out with a static type system, compared to a dynamic, for web development?

-- 
/Jacob Carlborg