Hi there,
I'm curious about writing some custom client listeners for different
messaging protocols on top of vibe-d. I'm curious about the best way
to go about doing this. E.g. if I want to handle messages sent over
RabbitMQ or something like that and have different handlers for various
message subjects.
Thanks
-S.
On Fri, 20 Mar 2015 23:43:15 -0700, Shammah Chancellor wrote:
Hi there,
I'm curious about writing some custom client listeners for different
messaging protocols on top of vibe-d. I'm curious about the best way
to go about doing this. E.g. if I want to handle messages sent over
RabbitMQ or something like that and have different handlers for various
message subjects.Thanks
-S.
In case of RabbitMQ, from a quick look, there see to be these options:
Generate bindings for the C implementation and use that from a separate thread to not block vibe.d's event loop (passing data back and forth for example using vibe.core.concurrency). This is probably the fastest solution to get something going, but is technically not optimal if performance is a primary concern.
Choose a nice implementation for a "similar" language (maybe C# or Go?) and port that to D, replacing the socket classes with vibe.d's TCPConnection in the process. See also http://vibed.org/blog/posts/writing-native-db-drivers.
Implement the protocol based on the specification. This has the potential to result in the most idiomatic D code, so that the language is used to its full potential, but is of course also the most involved approach.
Maybe there is a C/C++ implementation around that allows to register custom callbacks for performing socket I/O, so that vibe.d sockets could be injected. This would be similar to the BIO functionality of OpenSSL. See also here.
On a related note, there exists a native D/vibe.d implementation of an MQTT broker: http://code.dlang.org/packages/mqtt - Maybe that can serve as a source of inspiration.
On 2015-03-24 11:37:25 +0000, Sönke Ludwig said:
On Fri, 20 Mar 2015 23:43:15 -0700, Shammah Chancellor wrote:
Hi there,
I'm curious about writing some custom client listeners for different
messaging protocols on top of vibe-d. I'm curious about the best way
to go about doing this. E.g. if I want to handle messages sent over
RabbitMQ or something like that and have different handlers for various
message subjects.
Thanks
-S.
In case of RabbitMQ, from a quick look, there see to be these options:
- Generate bindings for the C implementation and use that from a
separate thread to not block vibe.d's event loop (passing data back and
forth for example usingvibe.core.concurrency). This is probably the
fastest solution to get something going, but is technically not optimal
if performance is a primary concern.
- Choose a nice implementation for a "similar" language (maybe C# or
Go?) and port that to D, replacing the socket classes with vibe.d's
TCPConnectionin the process. See also
http://vibed.org/blog/posts/writing-native-db-drivers.
- Implement the protocol based on the specification. This has the
potential to result in the most idiomatic D code, so that the language
is used to its full potential, but is of course also the most involved
approach.
- Maybe there is a C/C++ implementation around that allows to register
custom callbacks for performing socket I/O, so that vibe.d sockets
could be injected. This would be similar to the BIO functionality of
OpenSSL. See also
here.On a related note, there exists a native D/vibe.d implementation of an
MQTT broker: http://code.dlang.org/packages/mqtt - Maybe that can
serve as a source of inspiration.
Ah the MQTT Broker thing is helpful. I think I was making it more
complicated than needed to be. I was thinking that in the vibe-d
examples that listenTCP triggered the event loop somehow, but I suppose
that's done in main().
-Shammah
Am 27.03.2015 um 15:30 schrieb Shammah Chancellor:
Ah the MQTT Broker thing is helpful. I think I was making it more
complicated than needed to be. I was thinking that in the vibe-d
examples that listenTCP triggered the event loop somehow, but I suppose
that's done in main().-Shammah
Yes, exactly. There is a default main() implementation in
source/vibe/appmain.d that is used for most examples (by defining the VibeDefaultMain). listenTCP just starts listening and registers a
callback that is later called by the event loop. It doesn't block
execution and doesn't start any event processing by itself.
