> wrote:
>> Sorry, I meant if we go with (1), not (2), we might bump the size as
>> well, since we are already doing another ABI-breaking change.
>>
>> I agree on the solution as well.
>>
>> On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
>>> I
chumak.
> I am still undecided about the "zeromq organization", so I'll keep it in my
> repo for now. You're free to clone it if you like.
>
> New project can be found here:
> https://github.com/chovencorp/chumak
>
> On Sun, 14 Aug 2016 at 03:15 Pieter Hin
heckers (I tried it), and given
>> that typedef is only used externally to allocate the right size it
>> shouldn't actually affect anything, apart from the users of SPARC64
>> which should get the bugfix with this too. This is very sneaky :-)
>>
>> CC'ing La
FWIW I have come to believe that trying to design or even understand
the overall flows of data is a mistake, at least when you want to
scale.
What does scale is to speak of protocols and implementations. I know
this isn't a happy answer yet it's a proven one (RFCs, Internet).
On Wed, Aug 24, 201
;>
>> On Sat, 13 Aug 2016 at 16:18 Andriy Drozdyuk wrote:
>>>
>>> I see that you often accept pull requests yourself. Would I be able to
>>> accept PR on behalf of the project? Or are only the "admin" teams allowed to
>>> merge?
>>&g
gt;>> On Sat, Aug 13, 2016 at 8:52 PM, Andriy Drozdyuk
>>> wrote:
>>> > Agreed on the name. Will do.
>>> >
>>> > Oh phew, I thought you were beeing serious about the skype interview
>>> > there
>>> > for a second. :-)
>>>
ly the "admin" teams allowed to
> merge?
>
>
> On Sat, 13 Aug 2016 at 15:36 Pieter Hintjens wrote:
>>
>> The project is still owned by you and anyone else you select. There
>> are admin teams who get some rights over projects; I think we had one
>> case
We are using markdown for the RFCs and that does not support tables of contents.
The workaround we use in https://github.com/zeromq/gitdown is to embed
HTML tags in the markdown page, and then generate the markdown from a
.txt source file. We could use that same approach here; generate all
the RFC
"owned" by anyone at that point? What's to prevent me being
> removed from the "admins" (just hypothetical question)?
>
> On Sat, 13 Aug 2016 at 14:11 Pieter Hintjens wrote:
>>
>> You need to pay us a fee in small-unit BTC (to be discussed) and then
&g
You need to pay us a fee in small-unit BTC (to be discussed) and then
pass through the initiation ceremony, which involves firstly the short
6-hour Skype interview about your understanding of queuing theory as
it intersects with Conways' Law, then a longer Q&A session with the
Elders of the Zero, a
might fly if all you're worried
> about is ensuring patches to the project get recycled.
>
> Alex
>
>>
>> On Tue, 28 Jun 2016 at 16:28 Pieter Hintjens wrote:
>> This is really cool.
>>
>> The license choice will IMO hinder community growth around the p
This is really cool.
The license choice will IMO hinder community growth around the project
so I'd advise to you have a backup plan to switch to MPLv2 if the
commercial uptake isn't sufficient.
On Tue, Jun 28, 2016 at 7:09 PM, Andriy Drozdyuk wrote:
> At Pieter's suggestion, I am putting this he
Never mind, found it. You should be able to edit all pages in intro:
in a few minutes...
On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens wrote:
> Luca, what's your Wikidot login? I'll give you edit rights to that page/site.
>
> On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccass
Hi Dariusz,
I've made the change: https://github.com/zeromq/rfc/pull/108
-Pieter
On Thu, Jun 16, 2016 at 1:28 PM, Dariusz Suchojad wrote:
> On 14/06/16 10:45, Dariusz Suchojad wrote:
>> I'm simply not sure if I should also add information that this family of
>> protocols is subject to change at
Luca, what's your Wikidot login? I'll give you edit rights to that page/site.
On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi wrote:
> The messages to the announce list have been sent, and are awaiting
> moderator approval.
>
> Pieter, Doron, how do we update the get-the-software page?
>
> http://
ing? It is intentionally there to not clash, so
>> > > > maybe
>> > > > > solve this problem. Either by not generating them, either by defying
>> > > > safer
>> > > > > location.
>> > > >
>> > > > It's no
Have a look at Zyre, it deals with a lot of this.
On Thu, Jun 16, 2016 at 2:35 AM, Douglas Petican wrote:
> I've been working on req-broker-rep messaging pattern for an application and
> so far its working great. Thanks for the help. Right now it does what I
> need it to do for the current appl
C1FD09AA1A79977E6948DD50D4D
>
>
> On 2016-06-08 20:24, Pieter Hintjens wrote:
>>
>> The actual code is in zproject. The Zyre binding that it generates now
>> is pretty nice, it's just missing the ability to pass CZMQ classes
>> (like zmsg), which is what I was add
09:47, Johan Philips wrote:
>>>
>>> Pieter Hintjens imatix.com> writes:
>>>
>>>>
>>>> Yes, the more merges the better... I wanted this to go onto master
>>>> so others could play with it.
>>>
>>>
>>> Is someone pic
The approach we use in our projects has grown up without any formal
rules from C4. Anyone who wants to add a CI target can do so. So there
are CI targets for Travis, Jenkins, AppVeyor, etc. Lots of them. This
is disjoint from the development process in that it does not affect
e.g. whether a pull re
There will be WiFi and coffee... whether you want to hack or not, up
to you. (Hint: you probably want to bring your laptop :)
On Thu, Jun 2, 2016 at 11:24 AM, Luca Boccassi wrote:
> On Thu, 2016-05-19 at 16:55 +0200, Pieter Hintjens wrote:
>> Hi All,
>>
>> I'd like to
Yogesh, you need to use some form of credit based flow control.
On Wed, Jun 1, 2016 at 2:47 PM, Joshua Foster wrote:
> Multipart messages won’t help because they are sent atomically, ZeroMQ sees
> them as a single message.
>
> Joshua
>
>> On Jun 1, 2016, at 2:14 AM, yogesh fulsunge
>> wrote:
>
Your implementation can decide what versions of ZMTP it wants to
detect and support. Different versions use different formats. E.g. if
you want to support 3.0 and 3.1 then you'd allow both subscribe
commands, depending on the client's version. Note that version
negotiation is one-way: client states
You will need to use a ROUTER for the server and DEALER for the client.
On Wed, Jun 1, 2016 at 7:50 AM, yogesh fulsunge
wrote:
> Dear Team,
>
> I have gone through patterns and chapter 7 but not able to figure out the
> exact
> pattern to be used. I need to show to the client the pattern which i
Yes, simplest is to destroy the socket and create a new one.
On Tue, May 31, 2016 at 2:25 PM, Aaron Sokoloski wrote:
> Create an entirely new socket, maybe? In what situation do you want to
> unsubscribe from everything?
>
> On 31 May 2016 at 06:45, Bachmair Florian - flexSolution GmbH
> wrote:
I've spoken with Katriona, the lead on Exercism and she's going to add
the idea to the discussions. It's probably out of scope at the moment,
though you could think of an independent project that uses Exercism as
its base/inspiration.
On Wed, May 25, 2016 at 12:23 PM, Dinu Gherman
wrote:
> Hi,
>
If you read the Guide you'll find patterns that help you. Chapter 7
describes how to build such servers.
On Thu, May 26, 2016 at 4:21 PM, yogesh fulsunge
wrote:
> Dears,
>
> I am working on a design to replace CORBA interface between java swing
> clients ( around 1200) and C++ middleware Server i
OK, done here: https://github.com/zeromq/rfc/pull/95
On Mon, May 23, 2016 at 11:11 PM, Elliot Crosby-McCullough <
elliot...@gmail.com> wrote:
> 👍🏻
>
> On 23 May 2016 at 21:35, Pieter Hintjens wrote:
>
>> Yes, good catch. I need to double-check that, it may be that with
, cool. Does this line need updating then, as the NULL mechanism now
> describes client and server behaviours with regard to the sequencing of
> READY commands?
>
> https://github.com/zeromq/rfc/blob/master/spec_37.txt#L227
>
> On 23 May 2016 at 18:20, Pieter Hintjens wrote:
>
ity mechanism that doesn't
> set `as_server` for either peer should I assume that the binding peer is the
> "server" and the connecting peer is the "client", i.e. standard TCP
> terminology?
>
> On 23 May 2016 at 13:15, Pieter Hintjens wrote:
>>
>&g
I've made changes and sent a PR: https://github.com/zeromq/rfc/pull/93
On Mon, May 23, 2016 at 2:11 PM, Pieter Hintjens wrote:
> OK, there's an error in the explanation here. It's not symmetric. The
> client is the one that needs to send its READY upfront. The server is
>
e conflict between waiting
> for a READY, validating it, *then* sending your own READY as per the worked
> example, while the spec says to send READY without waiting for the other
> side to do so.
>
> All the best,
> Elliot
>
>
> On 22 May 2016 at 19:38, Pieter Hintjens w
Nice work. Just a comment on naming: I tried and failed to find the
packages, searching for "zeromq" and "libzmq".
I'd recommend not using "ZMQ" as an identifier. Instead use "libzmq,"
which is the real name of that project.
On Mon, May 23, 2016 at 6:12 AM, James wrote:
> Hi!
>
> I am currently
The partial read is to deal with older versions of ZMTP. Peers that do
this won't deadlock since as soon as they've read the first 11 bytes
they can send the rest of their own greeting, then they can validate
the socket type, send READY, then wait for a READY. Peers that don't
do backwards compatib
Viktor, ZeroMQ won't queue messages on disk, it's not designed for
this. You can build such pieces yourself fairly easily or use existing
higher-level queues like Malamute. Yet I think ZeroMQ is the wrong fit
for your case.
On Fri, May 20, 2016 at 11:57 AM, SZÉPE Viktor wrote:
> Thank you.
>
> Ba
Hi All,
I'd like to invite anyone who's in the neighborhood to join an all-day
meetup/patch party on June 4th in Brussels. The address is Rue des
Ateliers 15. No registration necessary. There will be wifi, seating,
coffee, drinks, snacks.
-Pieter
___
ze
Done, pull request made. The old .txt files can be removed in a next sweep.
On Wed, May 18, 2016 at 11:05 AM, Pieter Hintjens wrote:
> OK, I'll make the same structure.
>
> On Wed, May 18, 2016 at 10:58 AM, Yurii Rashkovskii wrote:
>> Pieter,
>>
>> this is grea
Yurii, thanks for bringing unprotocols.org to life with such a useful purpose.
On Wed, May 18, 2016 at 11:19 AM, Yurii Rashkovskii wrote:
> Hi,
>
> I had a thought that some of the protocols designed by ZeroMQ and other
> communities have really outgrown their communities and would really benefit
l surface.
>
> Yurii
>
> On Wed, May 18, 2016 at 1:56 AM, Pieter Hintjens wrote:
>>
>> OK, I'm writing some Perl to make the conversion and will push the .md
>> files when they're ready.
>>
>> On Wed, May 18, 2016 at 10:54 AM, Doron Somech wrote:
em with the
>> >>> > current
>> >>> > wiki; you have a solution, let's move ahead...
>> >>> >
>> >>> > On Wed, May 18, 2016 at 6:38 AM, Yurii Rashkovskii
>> >>> >
>> >>> > wrote:
>> >>
be more powerful, though). I’ve
>>> found this comparison, which doesn’t go very deep, though:
>>> https://civicrm.org/blog/michael-mcandrew/experiments-with-read-the-docs.
>>> You might be able to find better ones if you spend some more search cycles.
>>>
>&g
p the repo in place, convert the documents and set up a free
> gitbook.com account and change the CNAME to use gitbook.com (and even if
> they go out of business, it's fairly trivial to go the self-hosting route)
>
> On Tue, May 17, 2016 at 9:33 PM, Pieter Hintjens wrote:
>>
I think this is a great idea!
Your use of gitbooks for the event sourcing RFC proves it works. What
we use now is about ten years old; the Wikidot format works fine, so
does the platform, but we've fragmentation between the git repository
and the published RFCs.
It's fairly easy to convert the cu
It's not stable and not ready for production use.
You can build your own version of the NodeJS binding in
czmq/bindings/nodejs.
What needs to be done still is to finish the API so that CZMQ is properly
exported & wrapped. Most things work but it needs someone with NodeJS and
C++ knowledge to deal
Both will work.
In general when making such designs, take small incremental steps.
On Sat, May 14, 2016 at 8:38 PM, Leonardo José Consoni
wrote:
> Should I post my replies here as well or people would just follow the github
> issue ?
>
> ___
> zeromq-d
If you want to do controlled pub-sub, you're better using a
dealer-router pattern.
On Thu, May 12, 2016 at 4:46 PM, David Jelenc
wrote:
> Sachin,
>
> You can use xpub manual subscription. You can read more about it at
> somdoron's blog:
> http://somdoron.com/2014/12/token-pubsub
>
> Cheers
>
>
Use router-dealer or the new client-server sockets.
On Thu, May 12, 2016 at 1:21 PM, jean rouquet wrote:
> Hi,
>
> for a simulation project I have a classic Client Server model like, but the
> server should also be able to retrieve informations from client. The number
> of clients is static.
>
>
Kevin, this is really neat. :)
On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill
wrote:
> On 9/05/16 21:45, Kevin Sapper wrote:
>>
>> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
>
>
> Thanks for automating this. It looks great.
>
> This gives us two downloads per release (each in .
at 9:34 PM, Greg Young wrote:
> I am curious if anyone would be interested in trying to quantify the
> work involved with green threads on zmq actors?
>
> On Fri, May 6, 2016 at 10:29 PM, Pieter Hintjens wrote:
>> The current actor API is a bit simplistic. I'd have liked to re
The current actor API is a bit simplistic. I'd have liked to redesign
it using the new client/server sockets so that you could talk to
actors from any thread. As it is, there's no explicit mechanism to
check if actor X is running or not. You have to start the actor in
your main thread. You might be
The best way to understand what's going on is to look at the code for
mlm_client_content () and possibly debug by adding printfs as it runs.
This is really educational and will help you use Malamute better.
Please do read & follow coding style on all patches, space before '('
and noNamesLikeThis.
a submission and get slapped on the hand for doing what s/he
> thought was a benefit for the community.
>
>
> On Thu, May 5, 2016 at 1:57 AM Pieter Hintjens wrote:
>>
>> OK, I'm going to answer my own (stupid) question.
>>
>> - RFC 22 will be deprecated
>&g
OK, I'm going to answer my own (stupid) question.
- RFC 22 will be deprecated
- RFC 42 is the new version of C4 (revision 3)
- I'll stop using the cute form "C4.1"
So we can instead look at RFC42 and check that it's accurate.
-Pieter
On Thu, May 5, 2016 at 8:52 AM, Pie
Hi all,
I was writing a summary article on community building and revisited
the C4 RFC. There were many small things that were out of date,
speculative, or did not fit with our current best practice.
So I've updated it here: https://github.com/zeromq/rfc/pull/83
Please *do* read the diffs and le
If you want a lightweight ZeroMQ client library that supports IPC on
Linux, look at libzmtp. It is 1.3K lines of code with no dependencies.
https://github.com/zeromq/libzmtp
On Wed, May 4, 2016 at 1:21 PM, Osiris Pedroso wrote:
> I use ZeroMQ in Windows environment.
>
> This past week I ran Memo
e against CZMQ
> stable. If these are still considered draft and won't be built by default
> that's fine, I manage our zeromq / czmq packages and have custom ones
> anyway.
>
> Brian
>
> On Tue, May 3, 2016 at 8:13 AM Luca Boccassi
> wrote:
>>
>> On Tue, 2
'make dist'. It also makes us dependent on autotools.
On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens wrote:
> On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi wrote:
>
>> Is any of the API I marked as draft actually ready for release?
>
> Even so, leave it 'draft'
On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi wrote:
> Is any of the API I marked as draft actually ready for release?
Even so, leave it 'draft' until it's actually being used. Changing
minds is expensive otherwise.
> So should we use branches instead for bugfix releases?
All fixes to master.
> On Tue, May 3, 2016 at 11:39 AM, Pieter Hintjens wrote:
>>
>> Hi all,
>>
>> I'm just throwing some ideas on the table. We have a good package of
>> work on master and it's probably time to make a 4.2 release.
>>
>> Luca has already back-por
Hi all,
I'm just throwing some ideas on the table. We have a good package of
work on master and it's probably time to make a 4.2 release.
Luca has already back-ported the enable/disable draft design from
zproject (CZMQ et al). Yay! So we can now release stable master
safely, while continuing to r
Sounds like a free() being used somewhere instead of a zstr_free().
On Tue, Apr 26, 2016 at 10:17 PM, Osiris Pedroso wrote:
> Got latest zeromq (as of yesterday), built all in Windows using Dev2013.
>
> https://github.com/zeromq/malamute/issues/169
>
> Seems to only happen in those versions that
Yes, retiring the deprecated APIs and bumping the major version should go
together.
On 24 Apr 2016 13:37, "Luca Boccassi" wrote:
> On Sun, 2016-04-24 at 00:09 +0200, Pieter Hintjens wrote:
> > we can mark individual methods and classes as draft, even within a
> > stab
we can mark individual methods and classes as draft, even within a stable
release.
On 23 Apr 2016 21:10, "Brian Knox" wrote:
> When we cut another "stable" release of CZMQ to keep packagers happy, I'm
> wondering what version we'll use - specifically around a stable release
> that include radar/d
Thanks for the advice, Ewen. See here:
https://github.com/zeromq/libzmq/pull/1917
If you see things to fix, I'll make them before the patch is merged.
On Sat, Apr 23, 2016 at 3:39 AM, Ewen McNeill
wrote:
> Hi Pieter,
>
> [On list;
>
> On 23/04/16 4:31, Pieter Hintjens
ect.
>
> Not that I think it will be any issue but such an email is normally
> not admissable
>
> On Fri, Apr 22, 2016 at 5:31 PM, Pieter Hintjens wrote:
>> To whom it may concern,
>>
>> iMatix Corporation sprl, with address at 13-15 rue des Ateliers, 1080
&
,
under the Mozilla Public License version 2.
Pieter Hintjens
CEO, iMatix
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Sounds right to me.
On Mon, Apr 18, 2016 at 1:29 PM, Kevin Sapper wrote:
> Okay, seems I was a little bit to quick :(. Great analysis btw :)
>
> Your correct the client cannot recover from disconnected state. The
> heartbeat event has been overridden so the client itself will stop sending
> heart
Friends,
You know I've always steered our community with a light touch, only
intervening in case of the few disputes we get when bad actors think they
can waltz in and impose their egos. We agree that our rules work and that
those who understand and apply them with the right mix of tolerance for
e
OK, we need a small set of admins, who can work with my friend Ewen
McNeill, who has kept archives over the years, to migrate to mailmanlists
and then manage the lists (zeromq-announce is #2). Justin, it's your baby.
Thank you.
On 19 Apr 2016 05:10, "Pieter Hintjens" wrote:
Ju
Justin, that is a great proposal, thank you for finding it. I'd prefer
keeping mailman, for familiarity.
On 19 Apr 2016 04:36, "Justin Karneges" wrote:
> Hey folks,
>
> I spoke with MailmanLists and they are willing to host the ZeroMQ
> mailing list for free. All they ask for is a link on the mai
I trust Eben's judgement 100%
On 19 Apr 2016 02:34, "Michel Pelletier" wrote:
> I love reading Eben's work, thanks Stephen.
>
> Pieter, does this sounds like an option to pursue?
>
> On Mon, Apr 18, 2016 at 3:49 PM, Stephen Hemminger <
> step...@networkplumber.org> wrote:
>
>> On Mon, 18 Apr 2016
t;> -Michel
>>
>> On Mon, Apr 18, 2016 at 12:41 PM, Greg Young
>> wrote:
>>
>>> Route 53 is pretty simple to setup. If you are in lack of others we
>>> can maintain them.
>>>
>>> On Mon, Apr 18, 2016 at 10:39 PM, Pieter Hintjens wrote:
Hi folks,
I learned today that I'm terminally ill with lung cancer. Metastasis from
an incident five years ago. iMatix has run for 20 years and today consists
of myself as only active resource. This means we need to remove my firm as
a dependency.
Suggestions for a safe long term home for the dom
Robb, thanks for bringing this to the list. I hope someone will respond.
On 18 Apr 2016 14:47, "Robb Gosset" wrote:
> Hi,
>
> Pieter Hintjens reccommended contacting this mailing list for potential
> developers who may be able to work on the project. If anyone that's
Then again it puts Picasa in the same place, and that was replaced by Photos.
On Sat, Apr 16, 2016 at 12:03 AM, Pieter Hintjens wrote:
> Here's an interesting article I just found on the subject:
> https://www.gwern.net/Google%20shutdowns
>
> It puts the risk of Google shutting
Here's an interesting article I just found on the subject:
https://www.gwern.net/Google%20shutdowns
It puts the risk of Google shutting down Groups very low indeed.
On Fri, Apr 15, 2016 at 11:50 PM, Chuck Price wrote:
> I agree it can do the job. There is no guarantee it will be there tomorrow.
I don't understand half of what you're asking :) But in any case do
take a look at the tiny FSM / C code generator
(https://github.com/imatix/gsl/blob/b0aa393a6d00df2859f21aab0ccf6f203e18db96/examples/fsm_c.gsl)
that I've used happily in a few projects already.
On Thu, Apr 14, 2016 at 11:30 AM, al
Can you make a minimal test case that reproduces this?
On Thu, Apr 14, 2016 at 10:06 AM, Luka Napotnik
wrote:
> Hello,
>
> my client sends requests (as a DEALER socket) and the server (a ROUTER
> socket) handles the request and sends the reply back (taking the route
> path into account) . Now, a
t; If it would be more like google mail, I
>>> might like it.
>>>
>>> I would give Mailman 3 a try which should now have an interface decades
>>> better than Mailman 2, which is probably literally true if you skip the
>>> plural s.
>>>
>>&
Hi all,
I'd like to raise this question for discussion. The problem is that
zeromq-dev is running on an iMatix server, and I'd like to remove
iMatix infrastructure from our community, over time. It's a matter of
long term sustainability.
(Apart from the list, iMatix also hosts downloads.zeromq.or
at 10:59 PM, Matjaž Ostroveršnik
wrote:
>
>
> On 13.4.2016 22:37, Pieter Hintjens wrote:
>> gsl project.xml will not work from any folder; it will scatter
>> generated files all over the place.
>>
>> usage rule is you build the model, in its directory. Never use a path
ne from src folder, but it fails from
> different folder
>
> The same program, but two different behaviors. What is the usage rule
> for gsl?
>
> On 13.4.2016 21:59, Pieter Hintjens wrote:
>> Why are you trying to work around the design? If you could be explicit
>> abou
(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_proto.xml
> cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_client.xml
> cd $(srcdir)/src; gsl -topdir:.. -zproject:1 -q mlm_server.xml
> gsl -target:- project.xml
>
>
> On 13.4.2016 21:40, Pieter Hintjens wrote
No hypothesis. I'm telling you a fact. If you run gsl in the wrong
place *it will not work*. Please do not debug misuse.
On Wed, Apr 13, 2016 at 8:57 PM, Matjaž Ostroveršnik
wrote:
> Pieter hypothesis is that the src folder is hard coded. ;-)
>
>
> On 13.4.2016 20:10, Kevin Sapper wrote:
>
> Now
It’s set up to run from within src. So you must
cd src
gsl mlm_proto.xml
cd ..
I suspect you have the evil plan of trying to put all generated files
somewhere specific. It’s a neat idea but will not work, if you are
thinking of it. If not, forget I said anything :)
On Wed, Apr 13, 2016 at 7:50 P
On Sun, Apr 10, 2016 at 8:57 PM, Matjaž Ostroveršnik
wrote:
> c strings end with binary zero. Binary trackers can have zeros in the
> middle...
OK, treat 'string' as 'Semantics to be defined when someone gets
around to implementing this, and if not, delete as it's obviously
speculative.'
No poi
.
>
> BTW. I can't find a file with source code, where DEALER port selects socket
> to write to or read from (in case of multiaddress attach)
>
> Best regards
>
> Matjaž
>
>
>
> On 9.4.2016 21:35, Pieter Hintjens wrote:
>> On Sat, Apr 9, 2016 at 9:00 PM, Mat
On Sun, Apr 10, 2016 at 7:42 PM, Matjaž Ostroveršnik
wrote:
> What were conceptual reasons to make tracker as string? What is wrong with
> some integer value (e.g. uint32/64)?
Easier to generate guaranteed unique values, and messages that need
this kind of reliability tend not to worry about eff
On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik
wrote:
> "Source" and generated files in our solution are clearly separated and
> in different folders.
Not possible in our case due to independent layers of code generation,
often feeding into each other.
E.g. in CZMQ, we have:
* A tool that
Too many questions at once :)
- Async request-reply already works, using service requests, and
mailboxes for replies.
- For reliability, there is already a "tracker" field in messages. My
intention was/is that recipients can send CONFIRMs back for specific
messages. These flow asynchronously, and
Yes, you can use zmq_proxy for this.
On Sat, Apr 9, 2016 at 4:25 AM, vincegata wrote:
> Hello,
>
> Is it possible to "chain" PUB/SUB processes?
>
> By chaining, I mean:
>
> PUB --> SUB | PUB --> SUB
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lis
On Fri, Apr 8, 2016 at 9:43 PM, Matjaž Ostroveršnik
wrote:
> I managed to locally extend the mlm server with:
> - ability to make out of source builds for cmake
> - support for blobs for service interface
> - curve support
Nice stuff :)
I'm writing a book on how the development process for piec
For C/C++, CZMQ, Zyre, Malamute, and zproject. There are various
bridges to web services.
On Thu, Apr 7, 2016 at 8:59 AM, Laurent Alebarde wrote:
> Hi,
>
> That's more than two years I have not used 0MQ. I assume many things has
> changed in the time between. Reviewing the change log, I have to d
zproject headers to them.
>
> On Mon, Apr 4, 2016 at 5:36 AM Pieter Hintjens wrote:
>>
>> Hi all,
>>
>> I've been working on a NodeJS binding for CZMQ, using the code
>> generation approach of zproject. The first version (that builds) is
>> here: htt
OK, thanks. Done.
On Mon, Apr 4, 2016 at 1:01 PM, Doron Somech wrote:
> In the end, the For procrssing outgoing messages, the bullet " SHALL NOT
> block on sending." Is incorrect. Shell block, shloud not block if DONT WAIT
> is used
>
> On Apr 4, 2016 13:40, "Pieter
Doron, we need to fix the man page then. Can you read the RFC
http://rfc.zeromq.org/spec:41 and tell me which pieces exactly are
incorrect? I'll do the rest.
On Mon, Apr 4, 2016 at 10:04 AM, Doron Somech wrote:
> You have to specify ZMQ_DONT_WAIT for the send method to return eagain
> instead of
Hi all,
I've been working on a NodeJS binding for CZMQ, using the code
generation approach of zproject. The first version (that builds) is
here: https://github.com/zeromq/czmq/pull/1382
In theory this will let us generate NodeJS bindings for Zyre,
Malamute, and any other C libraries that use zpro
> stable one.
>
> Sent from my iPad. Regularly foiled by autocorrect. But duck it..
>
>> On Mar 27, 2016, at 03:37, Pieter Hintjens wrote:
>>
>> Two things here. First, the project itself can have various states.
>> There are two that interest us:
>>
>
Two things here. First, the project itself can have various states.
There are two that interest us:
* all draft, nothing has been marked stable yet.
* some parts marked as stable (and released), others are draft.
In the first case zproject should export the whole API (in the project
header file).
No, you cannot drop older messages in pipe buffers to make space for
newer ones. This is technically impossible without slowing things down
considerably.
A good approach is to use credit-based flow control to avoid ever
sending more data than the receiver expects and asks for. There's a
discussion
1 - 100 of 5367 matches
Mail list logo
