On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:
> Completely off-topic, but:
>
> Have you considered making vibe http-backend independent?
> So that it could provide a fcgi interface or be included in an nginx
> plugin?

What is the benefit as opposed to using proxy_pass at nginx? fcgi will be slower than built-in vibe.d HTTP server.

On 7/9/2014 10:49 AM, Chris wrote:
> On Wednesday, 9 July 2014 at 01:35:49 UTC, Puming wrote:
>
>> That commenter is probably a web developer that wants all batteries
>> included.
>
> Yep. He mistook vibe.d for a complete web development framework, I
> suppose. It's quite common that people are put off because they expect
> too much or do not understand what the technology is really about. While
> we may not win this particular user back, it is important to clarify
> where s/he was mistaken, so that myths based on false assumptions are
> not propagated.
>

Can't it be used as a complete web framework? I mean, assuming you're happy with the built-in templating and DB options? Or is everyone using "web framework" here to really mean "CMS"?

Am 09.07.2014 19:03, schrieb Johannes Pfau:
> Am Wed, 09 Jul 2014 18:16:49 +0200
> schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:
>
>> Am 09.07.2014 17:26, schrieb Sean Kelly:
>>> On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote:
>>>> Also, in playframework, vert.x and nodejs, they all have a
>>>> plugin/module system, that people could easily compose plugins to
>>>> make a website. (I call it plugin because that is what play used
>>>> to call it, now they all call it a module but that name will
>>>> easily conflict with D's sourcecode modules). This is a critical
>>>> mechanism that actually allured developers to contribute to the
>>>> eco-system.
>>>
>>> On a related note, one thing vibe.d is really missing from my
>>> perspective is a good way to handle unstable processes and perform
>>> seamless code upgrades (this is where Erlang really shines IMO).  It
>>> would be cool if there were a process monitor at least.  The system
>>> I work with does some fancy stuff with UDS, but that probably isn't
>>> necessary.  I'll admit that the ball is probably kind of in my court
>>> here, since IPC would be a handy way of communicating process
>>> health, but something simpler using pipes or whatever would work as
>>> well.
>>
>> This is what vibedist [1] was/is intended for, but unfortunately I
>> never found the time to really finish it so far.
>>
>> [1]: https://github.com/rejectedsoftware/vibedist
>
>
> Completely off-topic, but:
>
> Have you considered making vibe http-backend independent?
> So that it could provide a fcgi interface or be included in an nginx
> plugin?

That could be done pretty easily by providing an alternative to listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)). It could use the HTTPServerRequest and HTTPServerResponse classes more or less just like the HTTP server does.

>
> Also as D plugins now seem to work more or less have you considered
> loading webpages dynamically from .so files?
>
> Then we could invent some file extension - like .dpage - and have one
> vibe fcgi process handle all .dpage files. The process then simply
> loads the .dpage shared library, calls some function (extern(C) IWebSite
> vibe_get_site()) etc.
>
> Basically the way asp.net works, IIRC.
>

That would be pretty much what Rikki Cattermole is planning to do with Cmsed [1]. For vibe.d it would be a bit too much at this time. There is still a lot that I would like to get done on the lower levels of the library, so that the basis is really solid sooner rather than later. The highest level features planned for now are the descriptive REST and web interface modules.

However, there is a plan for using dynamic libraries to support seamless live editing/reloading of individual Diet templates [2].

[1]: http://code.dlang.org/packages/cmsed
[2]: https://github.com/rejectedsoftware/vibe.d/issues/676

From my usage of vibe.d thus far, I've found that it has a lot of things I want if I were to use it for building sites like the sites I build at work. vibe.d can offer excellent performance and scalability, and those are great building blocks to have for building a great web framework. I think what's missing from vibe.d lies in D code yet to be written which is required to get a decent level of productivity.

I am primarily a Django developer these days, and Django has some great features which boost my productivity massively. I'd want to see the same features, only written in a way more appropriate for D, in vibe.d. Here's a short list.

* An ORM, which absolutely must have a way to build queries a piece at a time without writing any SQL, like Django.
* A framework for generating all of the SQL required for database migrations like South or the built in migrations in Django 1.7, so you can quickly change any model.
* An API for creating form handlers, especially for creating instances of models in the ORM through forms. (Django Form and ModelForm)
* An HTML template system which doesn't eat memory at compile time and where changes can be made while the development server is running.

Those are the important "must have" points. Because of these features in Django, I can create a new feature for a website in the space of a couple of days, wildly restructure databases for optimisations etc. There are a few other tools I use in Django that are very nice to have.

* Django's automated testing framework lets you test pages with session data and email output, so I have tests for complex things like checkouts which are very easy to write. I pair it with a Jenkins module so I can use Jenkins locally for CI.
* The django-debug-toolbar module saves a ton of time when optimising queries. I use it for loading pages and looking at all of the queries run in a timeline with all of the EXPLAIN output right there. As a result I have massively improved query times at my job.
* The Django pipeline module provides mechanisms for generating JS and CSS. I now have SCSS which regenerates CSS automatically during development without needing a filesystem monitor like Compass, and I have cut load times on a couple of pages by a second each by merging JavaScript together. (Even without minification, which it supports, which I haven't gotten to yet.)

So there's my wishlist. I see it as a TODO list of things I or someone else should write. I'd be willing to contribute to a few of those points whenever I have time.

On 7/9/2014 11:21 AM, Sönke Ludwig wrote:
> Am 09.07.2014 03:54, schrieb luminousone:
>> There is lots of missing little bits here and their, password hashing
>> functions that use crypt_(C) formated hashes.
>
> I was hoping for dauth [1] to fill that gap. It doesn't use the same
> format, but one with the same goal. I didn't actually try it out yet,
> though.
>

I admit I'm unfamiliar with this "crypt_(C) formated hashes", I'll look it up and try to support it. Anyone happen to have a link handy?

Also, if anyone has ANY issues/concerns/questions/anything about DAuth, PLEASE speak up or submit an issue at github. I want DAuth to work well for everyone :)

Speaking of DAuth future direction, I may as well mention this and open it for comment:

My plan ATM is to expand DAuth's scope a little, split it into about three main components (at different levels of abstraction) and rename to something less likely to be mistaken for an OAuth lib (DAuth is unrelated to OAuth).

I'm thinking of something like this:

"InstaUser Core": Basically what DAuth is now. Provides the two main primitives "Convert plaintext password to a salted hash" and "Validate plaintext password against a salted hash". Plus all the optional lower-level stuff like dealing with salts/hashes/etc directly, selecting hash algos directly, customized salted-hash formats, one-use tokens, etc.

"InstaUser Store": I've already started work on this locally. Basically a simple (compile-time, static linked) plugin architecture that provides basic user-management primitives (create user, change user's password, validate a password against a user, delete user, etc) with pluggable storage backends ("Stores") like MySQL. Various storage backends would be included.

"InstaUser Web": This would leverage vibe.d to provide an out-of-the-box working (and customizable) web-based register/login system. I expect that some applications may (or might not) outgrow this, but I think it would be fantastic for getting a login-based site off the ground and up-and-running. Or even just putting files (like webalyzer stats) behind a login that isn't "HTTP auth". I've written/maintained sooo many web login systems over the years I've gotten sick of reimplementing sooo many of the same things every time and backporting all newer improvements (Which is really the whole original reason I started DAuth in the first place).

An application can use *just* Core and omit the Store/Web stuff entirely. Or they can use it at the Store level. Or at the Web level. Or make direct use of all the levels.

Further in the future, "InstaUser" could possibly grow support for the "login in via Facebook/Gmail/OpenID/whatever" that seems to be popular now, or whatever other authentication systems may be useful.

"Destroy!"

>
> [1]: http://code.dlang.org/packages/dauth

On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:
> Am 09.07.2014 03:54, schrieb luminousone:
>> There is lots of missing little bits here and their, password hashing
>> functions that use crypt_(C) formated hashes.
>
> I was hoping for dauth [1] to fill that gap. It doesn't use the same format, but one with the same goal. I didn't actually try it out yet, though.
>
>>
>> There are diet/jade template bugs still, specific major problem being
>> that use of single quotes inside of double quotes when i need to pass
>> strings to js functions inside of js events such as onclick inside a
>> html tag, seems to be broken.
>
> Do you have a concrete example where this goes wrong? I've tested both, nesting ' inside " and vice versa. Both seemed to work fine for <body onLoad=...>.
>
>>
>> There is not common database interface for sql databases(forgivable
>> actually), but many of the specific database libraries are messy(ddb for
>> example) and they are not any where near api "stable".
>>
>> Support for mongo is... cute?!, don't get me wrong it has a place, for
>> most apps it would be fine, it is however unusable for the apps i am
>> involved in.
>
> Yeah, I kind of like it for its flexibility, but it's definitely not the right choice for million user web services. I'm currently looking at NouDB as another potential SQL based target.
>
> [1]: http://code.dlang.org/packages/dauth


hopefully, these posts are simply read as text, if not I can
figure out something else.

a.menu_item(href='#', onclick='load("invoice");') New Invoice
a.menu_item(href='#', onclick="load('invoice');") New Invoice

will always generate the following output,

<a href="#" onclick="load(&quot;a&quot;);" class="menu_item">New
Invoice</a>
<a href="#" onclick="load(&#39;invoice&#39;);"
class="menu_item">New Invoice</a>

On 7/9/2014 3:05 PM, w0rp wrote:
>
> * An API for creating form handlers, especially for creating instances
> of models in the ORM through forms. (Django Form and ModelForm)

What I've started doing, and absolutely love so far, is to write my forms purely in the HTML template (with a little bit a custom tags/attributes), then use Adam's HTML DOM to read that HTML form and generate all the backend form-handing *from* the HTML form, including all the appropriate per-field "validation failed".

I'm finding this works a lot better than defining forms in the backend code and then trying to generate the HTML I want from that.

> * An HTML template system which doesn't eat memory at compile time and
> where changes can be made while the development server is running.
>

Mustache-D:

https://github.com/repeatedly/mustache-d

Unfortunately it *only* supports runtime processing right now, but it's a fairly nice little templating system. The claims of being "logicless" are total BS, but a *truly* logicless system would be useless anyway.

On Wednesday, 9 July 2014 at 15:17:03 UTC, Sean Kelly wrote:
> Huh.  I guess it depends what your goal is.  For the kind of work I do, vibe.d is in the right ballpark.  The services I create basically respond to AJAX calls (JSON-RPC is the best, though REST is okay too) and do other back-end work.

The JSON stuff may be nice, but I would prefer some more rigor (I am writing mostly c++ desktop apps, for the server side I am still open). My 'vision' is a stack with Vibe, Thrift and PostgreSQL. Everything plugged inside the vibe's async io and its own task/fiber concurrency. I think a good direction would be to dispatch the in-proc-service method calls with vibe's concurrency/task message passing. This would bring 'async' by default (a service would yield as is waits for database or other services) and it would guarantee that the requests are processed serially by a service (no concurrency or reentrancy problems). Bonus points if the services can be easily moved from in-process to other machines.

On 2014-07-08 9:32 PM, Puming wrote:
> Also, in playframework, vert.x and nodejs, they all have a plugin/module
> system, that people could easily compose plugins to make a website. (I
> call it plugin because that is what play used to call it, now they all
> call it a module but that name will easily conflict with D's sourcecode
> modules). This is a critical mechanism that actually allured developers
> to contribute to the eco-system.

This is phenomenal work from my perspective because it needs to be original to justify the move. However, I was too tempted by the functional nature of D and my imagination motivated me to build the technicalities for some huge infrastructures behind a next-gen CMS.

I have a chart up at https://github.com/globecsys/spee.d about what's involved with it, on my schedule for all components there should be at least 300 hours of work left.

I'm aiming for a standalone executable library-oriented framework, which would give a cross-platform wordpress-like CMS installation that technically should scale _infinitely_. There's a few issues with infinite scalability behind NAT firewall nodes, like

- the solution would be a websocket communication with (http://wamp.ws/) a more advanced protocol is elementary.
- a cache database (I have a local redis-like one up called cache.d) needs to "talk" to hash-distributed master DBs with replication
- this cache database would be modified to take advantage of the GC to avoid making additional copies on a server (store some void* in memory, serialized data on the filesystem).
- library support would be with the same interface as wordpress: add_filter, add_action, etc - but a focus on Backbone.marionette for front-end js-based structuring with REST/json backend data provider
- a custom D-based TLS library would help maximize code inlining in the streams and minimize points of attack
- a DER and length-value serialization library would help minimize boilerplate

I'm still brainstorming on the geolocation and domain-clustering of master nodes and load balancing.

I'm finishing up work on a completely generic ASN.1 compiler with support for Information Objects that generates D structures for TLS: https://github.com/globecsys/asn1.d

This is necessary because there's over 7000 lines of structure definitions involved: https://github.com/globecsys/asn1.d/blob/master/tls.asn1

Anyways, enough typing about this for the moment, I'm not looking for help :)

Am 09.07.2014 21:19, schrieb Nick Sabalausky:
>
> "InstaUser Web": This would leverage vibe.d to provide an out-of-the-box
> working (and customizable) web-based register/login system. I expect
> that some applications may (or might not) outgrow this, but I think it
> would be fantastic for getting a login-based site off the ground and
> up-and-running. Or even just putting files (like webalyzer stats) behind
> a login that isn't "HTTP auth". I've written/maintained sooo many web
> login systems over the years I've gotten sick of reimplementing sooo
> many of the same things every time and backporting all newer
> improvements (Which is really the whole original reason I started DAuth
> in the first place).
>
> An application can use *just* Core and omit the Store/Web stuff
> entirely. Or they can use it at the Store level. Or at the Web level. Or
> make direct use of all the levels.
>
> Further in the future, "InstaUser" could possibly grow support for the
> "login in via Facebook/Gmail/OpenID/whatever" that seems to be popular
> now, or whatever other authentication systems may be useful.

This was also exactly my idea with the "userman" [1] and "user-auth" [2] packages, although I didn't get very far with the "user-auth" part, yet. Maybe we can join forces there. (Please excuse the awfully creative names, I created a lot of packages at once at the time ;)

[1]: https://github.com/rejectedsoftware/userman
[2]: https://github.com/rejectedsoftware/user-auth