View mode: basic / threaded / horizontal-split · Log in · Help
April 29, 2012
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d! SOAP .. REST?
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d! SOAP .. REST?
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home