March 25, 2012
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
March 26, 2012
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.
March 26, 2012
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.

Amazing! Well-done Adam!
March 27, 2012
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)
March 27, 2012
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).
March 27, 2012
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? :-)
1 2
Next ›   Last »