Doron - I think we can get away with not supporting multi part. We're
mainly interested in PUB / SUB and CLIENT / SERVER support. With CLIENT /
SERVER being able to stand in for ROUTER / DEALER and not requiring multi
part messages - I think we can ignore multi part for what we're doing.
I've go
Brain I will love to help and improve my golang on the way.
Small tip, if you don't need multi-parts it will make your implementation
much easier.
If you do need, using the "commit" solution of libzmq is very complicated,
try to unified all the parts into one data structure and enqueue it into a
c
The name is :)
On Sat, Oct 10, 2015 at 4:31 PM, Brian Knox wrote:
> Pieter - yup! I've looked at the libzmtp code before - it + the zmtp rfc
> combined are a good reference.
>
> We're going to keep the name "gogozmq" for now mainly because we like saying
> "go go zmq!" a lot. It may not be the
Pieter - yup! I've looked at the libzmtp code before - it + the zmtp rfc
combined are a good reference.
We're going to keep the name "gogozmq" for now mainly because we like
saying "go go zmq!" a lot. It may not be the best name, but it has the
important property of making me smile whenever I sa
Go go zmq! :-)
This is a great idea. I'm going to suggest modestly that "gomq" could
work better as a name. "gogozmq" looks like a binding name.
FWIW we started on a small C library (libzmtp) and what we made was a
DEALER socket. This is immediately useful, and could be a good
starting point.
-P
Luna and I have been talking about implementing a subset of ZeroMQ in pure
go to complement goczmq for people who don't want C dependencies. It would
solve a great set of problems for both of us and we feel would be useful to
others as well.
We wanted to give a heads up that we're going to create
