April 29, 2012 Re: Introducing vibe.d! | ||||
---|---|---|---|---|
| ||||
Posted in reply to simendsjo | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to simendsjo | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bls | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mirko Pilger | 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! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
Copyright © 1999-2021 by the D Language Foundation