On 10/07/2014 9:12 a.m., Johannes Pfau wrote:
Am Wed, 09 Jul 2014 20:34:49 +0200
schrieb Sönke Ludwig <slud...@rejectedsoftware.com>:
Am 09.07.2014 19:03, schrieb Johannes Pfau:
Am Wed, 09 Jul 2014 18:16:49 +0200
schrieb Sönke Ludwig <slud...@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
I see, thanks. I think a CMS is usually a little higher-level then what
I meant. But of course a name doesn't say much about what a project
actually is ;-)
Unfortunately right now Cmsed doesn't for-fill its purpose in the CMS
area. But basically I use dub sub packages so if you didn't want to go
full in, you didn't need to.
I.E. the base web service framework is literally called cmsed:base and
it would give you most of the nice ness e.g. router, javascript
generation and Dvorm integration (ORM and works rather well in my opinion).
Where as cmsed:user would provide just user authentication and storage
mechanism.
