On 2011-07-14 13:21:32 +0200, Trass3r said:

> http://arsdnet.net/dcode/

Thanks (for this link and the other related posts). I'll give it a try and play around with it. The session stuff can be kept simple via cookies or a REST interface ID.

-- 
Robert M. Münch
http://www.robertmuench.de

On 2011-07-14 16:00:33 +0200, Long Chang said:

> I create one , fastcgi & template is done , but I need dynamic link lib of posix support , ...

I'll take a look at the fastcgi stuff. IMO it makes sense to use this to reduce process creation times.

-- 
Robert M. Münch
http://www.robertmuench.de

> IMO it makes sense to use this to reduce process creation times.

Process creation is a very small cost with D programs. It's nothing to worry about unless you have real world data to the contrary for your project.

My cgi.d though supports standard cgi, fast cgi, and an embedded
http server, if you have the right add on libraries. (The C language
fast cgi lib available from the fast cgi people or my netman.d and
httpd.d for the embedded. Of those two, I recommend fastcgi - my thing
is actually faster, but less reliable and potentially insecure.)

The app side interface is identical in any case, so switching out is as simple as a recompile.

Nick Sabalausky wrote:
> But, HEAD is technically required (though I have no idea what the real-world use-cases are), so I'm not quite sure what to do.

Actually, I'd be surprised if your web server didn't handle it... it can just send a GET to your app then simply discard the response body.

As for use, I think it's actually a carryover from http 1.0, rendered almost useless in http 1.1 thanks to it's conditional get. I believe they weren't in 1.0, so if you wanted to check for a new version of a page, instead of saying "get if modified since", you'd do a HEAD and check the last modified header yourself, then issuing a separate GET if it's old enough.

Obviously, a conditional get is a much better way to do it.


The only two things I find HEAD useful for myself are:

a) testing. It's nice to be able to manually do a request and not be spammed by a million lines of body when I just want to see headers.

b) making sure a file is a reasonable size before downloading. Since content-length is one of the headers in this, you can check the size and present it to the user to cancel if it's unreasonable.

I don't think there's another way to do (b) in the 1.1 version. It's
definitely how I'd do it.

Nick Sabalausky wrote:
> Does your undo stack persist after the editor (or the file) is
> closed? How big is the undo stack? How easy is to undo to a specific
> working (ie, not "in the middle of a task") state?

It /can/ do them all, though I personally only the infinitely sized undo stack part. (I use vim, which can do branched and timed undo stacks. I think it can name them too but I'm not sure)

I'm also more likely to comment something out than to actually remove it.

> Another big thing is that it makes it much easier to fold in user-submitted changes.

Indeed, though I try to avoid those situations too!

> BTW, Tip from experience: Save yourself the sanity and never bother trying to deal with hg-git

I actually mostly like the git command line program.

On 7/15/11 4:26 PM, Adam Ruppe wrote:
>> IMO it makes sense to use this to reduce process creation times.
>
> Process creation is a very small cost with D programs. It's nothing
> to worry about unless you have real world data to the contrary for
> your project.

Doesn't that apply more to Unix than to D?

One of the paradigm shifts incurred when I moved to Unix from Windows was how incredibly cheap it was to create processes on Unix, and how many great idioms derive from that. In Windows one gets used to thinking creating a process is a big deal, which requires a fair amount of unlearning.


Andrei

> One of the paradigm shifts incurred when I moved to Unix from Windows was how incredibly cheap it was to create processes on Unix, and how many great idioms derive from that. In Windows one gets used to thinking creating a process is a big deal, which requires a fair amount of unlearning.

So true.

Andrei Alexandrescu wrote:
> Doesn't that apply more to Unix than to D?

Somewhat, though a lot of the CGI flames from the day were coming from unix machines.

There's two factors (I speculate) that contributed to it:

a) Linux used to be slower at forking and execing than it is now.

b) Most cgi apps were Perl, which meant starting up the interpreter,
   compiling the file, etc. in addition to the fork/exec.


(b) is where the difference with D comes in - it's already compiled, so no need to take that extra step.

Just a general comment... my D web stuff is spoiling me.

Guy just asked me for a form based file uploader. With web.d:

===
import arsd.web;
import std.file;
class SiteAdmin : ApiProvider {
    override void _initialize() { cgi.requireBasicAuth("user", "pass"); }

    string uploadNewVideo(Cgi.UploadedFile file) {
         std.file.write("desiredfile", file.content);
         return desiredfile;
    }

    override Document _defaultPage() {
         return _getGenericContainer().
            appendChild(_sitemap()).parentDocument;
    }
}
mixin FancyMain!SiteAdmin;
===

Boom. The library will auto-generate the form and some basic html output and a list of links to the pages.

Compiling that little snipped will give me something
I could show to him *right now*. And I can expand it later with
ease. This one has a simple HTTP hard coded username and password
which works for now and can again be trivially changed later.

But alas, this job needed to be PHP. PHP is supposed to make file uploads easy, but I have to look up the stuff every time.

(just like how I have to look up the args to PHP str_replace
every time... and I often forget Javascript substr or substring?
In D, "string".replace("this", "that")[0..5]; is trivial to
remember.)

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:ivr07p$8cq$1@digitalmars.com...
> Just a general comment... my D web stuff is spoiling me.
>
> Guy just asked me for a form based file uploader. With web.d:
>
> ===
> import arsd.web;
> import std.file;
> class SiteAdmin : ApiProvider {
>    override void _initialize() { cgi.requireBasicAuth("user", "pass"); }
>
>    string uploadNewVideo(Cgi.UploadedFile file) {
>         std.file.write("desiredfile", file.content);
>         return desiredfile;
>    }
>
>    override Document _defaultPage() {
>         return _getGenericContainer().
>            appendChild(_sitemap()).parentDocument;
>    }
> }
> mixin FancyMain!SiteAdmin;
> ===
>
> Boom. The library will auto-generate the form and some basic html output and a list of links to the pages.
>

Cool :)

> Compiling that little snipped will give me something
> I could show to him *right now*. And I can expand it later with
> ease. This one has a simple HTTP hard coded username and password
> which works for now and can again be trivially changed later.
>
> But alas, this job needed to be PHP. PHP is supposed to make file uploads easy, but I have to look up the stuff every time.
>

And whatever you end up with is most likely to have a bunch of subtle problems, and could easily break if moved to another server, even if you're lucky enough to have the same exact build of PHP on the new server.

> (just like how I have to look up the args to PHP str_replace
> every time... and I often forget Javascript substr or substring?
> In D, "string".replace("this", "that")[0..5]; is trivial to
> remember.)

Slicing is such a killer feature if, like me, you've come from langauges like C/C++/Java (or PHP).