Am 29.04.2012 11:52, schrieb simendsjo:
> On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig
> <sludwig@outerproduct.org> wrote:
>
>> Quote
>> Additional drivers are easy to port to vibe.d because of the blocking
>> API - basically the only thing that has to be done is to replace the
>> socket calls (send(), recv(), connect() etc.) with the corresponding
>> vibe functions.
>> EndQuote
>> Can you elaborate a bit more ? Maybe using the vibe.d blog.
>> Good idea, it will put something together.
>
> Something wrong with the blog engine? The published post doesn't show in
> the list, and it's cut off in the middle without any way to expand it:
> http://vibed.org/blog/posts/writing-native-db-drivers

It was a bug in the RSS generator. I just added the article without content to not forget about it but didn't publish it yet. The RSS generator, however, published it anyway.

Am 29.04.2012 15:22, schrieb Jacob Carlborg:
> On 2012-04-29 10:07, Sönke Ludwig wrote:
>
>> The static this() pattern is mainly there to appeal to users of similar
>> systems in script languages, where you don't have a main function at all
>> and just happily hack away. For larger projects it doesn't make a
>> difference but for small projects it can actually be quite convenient.
>
> Since you can't have code (besides declarations) at the module level I
> don't see how "static this" would be than "main".
>

You just don't have to care about how to parse command line arguments, how to initialize the library and to start the event loop.

i would like to know a bit more about those "extension modules for vibe" and the "vpm registry". e.g. can i write yet another web framework on top of the vibe io modules as an "vibe extension" and would you even encourage this?

On Sunday, 29 April 2012 at 08:52:09 UTC, simendsjo wrote:
> On Sun, 29 Apr 2012 08:13:40 +0200, bls <bls@orange.fr> wrote:
>
>>
>> There is also a socket based PostgreSQL driver available, but I have lost the link and dunno about the status quo.
>
> This? https://github.com/pszturmaj/ddb

Exactly. Thanks for the pointer, It is pretty hard to create a common db- interface.

On Sun, 29 Apr 2012 20:28:38 +0200, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> It was a bug in the RSS generator. I just added the article without content to not forget about it but didn't publish it yet. The RSS generator, however, published it anyway.

Yeah, I was pretty quick to find out how to subscribe to the RSS feed :)

Seems that my last reply was jammned or whatever .. so in short
x509 certificate support...  Why not ?

SOAP/WSDL
SOAP service consuming is what makes my bread and butter nowadays but
to face it : Parsing a WSDL stream sucks
Creating a SOAP service in D is .... Ouch..  Consuming a SOAP/WSDL in D is  super...... anyway,  Smart Devices are not realy interested in SOAP/WSDL...
Means Vibe.d should support REST out of the box.

I hope that you give ---- Interface to REST ------ (code-gen-wise) a try..
Bjoern

On 2012-04-29 20:29, Sönke Ludwig wrote:

> You just don't have to care about how to parse command line arguments,
> how to initialize the library and to start the event loop.

Right, didn't thought of that. Would it be a good idea to allow top level code and use "import" and mixin the code in some context, i.e. :

// foo.d

auto settings = new HttpServerSettings;
settings.port = 8080;
listenHttp(settings, &handleRequest);

Then somewhere:

// vibe.d

void main (string[] args)
{
    handleCommandLine(args);
    init();
    mixin(import("foo.d"));
}

-- 
/Jacob Carlborg

Am 29.04.2012 23:41, schrieb bls:
> Seems that my last reply was jammned or whatever .. so in short
> x509 certificate support... Why not ?

Do you mean for SSL or package signing or something else? They are currently used for SSL, but currently there is no certificate validation on the client side.

>
> SOAP/WSDL
> SOAP service consuming is what makes my bread and butter nowadays but
> to face it : Parsing a WSDL stream sucks
> Creating a SOAP service in D is .... Ouch.. Consuming a SOAP/WSDL in D
> is super...... anyway, Smart Devices are not realy interested in
> SOAP/WSDL...
> Means Vibe.d should support REST out of the box.
>
> I hope that you give ---- Interface to REST ------ (code-gen-wise) a try..
> Bjoern

If you mean automatic generation of a REST interface for an existing D interface, then it's definitely planned. I can imagine a sloppy version where the HTTP method is always POST or can be POST/GET as desired by the client. But I would also like to have a more expressive version, where the HTTP method is inferred from the D method somehow and maybe it would also be possible to specify a sub path for each method.

Sönke

Am 29.04.2012 21:57, schrieb Mirko Pilger:
> i would like to know a bit more about those "extension modules for vibe"
> and the "vpm registry". e.g. can i write yet another web framework on
> top of the vibe io modules as an "vibe extension" and would you even
> encourage this?

Essentially a VPM module nothing more that a normal library that has vibe.d as a dependency. It can also have additional VPM dependencies and can bring its own template files and resources. What you do with it is basically not really limited. I wouldn't say it really is a good idea to implement alternatives to large parts of the existing libraries, as that would just fragment everything (->tango/phobos). But in general its definitely possible.

Currently VPM modules should just adhere to the structure in http://vibed.org/docs#first-steps and have to have an additional URL field in the package.json with a direct download link (at least for now it must be a github repository zipball link). I can then put it manually into the registry so that anyone automatically gets it as soon as some project adds it as a dependency.

A proper user inferface for registry.vibed.org is planned as the next step, as well as TAG support for github repositories to mark release versions.

Am 30.04.2012 08:22, schrieb Jacob Carlborg:
> On 2012-04-29 20:29, Sönke Ludwig wrote:
>
>> You just don't have to care about how to parse command line arguments,
>> how to initialize the library and to start the event loop.
>
> Right, didn't thought of that. Would it be a good idea to allow top
> level code and use "import" and mixin the code in some context, i.e. :
>
> // foo.d
>
> auto settings = new HttpServerSettings;
> settings.port = 8080;
> listenHttp(settings, &handleRequest);
>
> Then somewhere:
>
> // vibe.d
>
> void main (string[] args)
> {
> handleCommandLine(args);
> init();
> mixin(import("foo.d"));
> }
>

Interesting haven't thought about going that far :)

Somehow that reminds me of:
#define IF if(
#define THEN ){
#define ELSE } else {
#define ENDIF }

to transform C into BASIC. The scripting-only people would probably be thrilled ;) But I have the tendency to think that this bends the language a bit too far. They will also soon wonder why they cannot put top-level code in their other files.

Sönke