April 29, 2012
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.
April 29, 2012
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.
April 29, 2012
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?
April 29, 2012
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.
April 29, 2012
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 :)
April 29, 2012
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
April 30, 2012
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
April 30, 2012
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
April 30, 2012
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.
April 30, 2012
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
1 2 3 4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home