[zeromq-dev] Meetup in Chicago, Oct 20

[Chuck Remes]

On Oct 20, 2011, at 10:12 AM, Pieter Hintjens wrote:

> On Thu, Oct 20, 2011 at 9:55 AM, Chuck Remes <cremes.devlist at mac.com> wrote:
> 
>> We are having a bit of crazy weather in Chicago with high winds and a lot of rain. Hopefully this doesn't cause any problems for Pieter to join us today.
> 
> :-) No problem.

Good!

>> Here are a few topics I might bring up tonight.
>> 
>> * Purpose of "4.0" and its impact on 3.0
>> * Recruit help to revise code examples for 3.x api
>> * Discuss interest in a "transport API" for 0mq so it's easier to add other protocol transports (SCTP, Infiniband, carrier pigeon)
>> * Protocol gateways (0mq to HTTP, FIX, etc)
> 
> That's a good list. The last two points are the same IMO. I'd started
> on a transport API last year (VTX) but got side-tracked for various
> reasons. Already got UDP working with it and started on TCP. Mainly it
> needs a real project willing to push the work.

Good point. Maybe we can take a straw poll of the attendees to see if there is any work that they or their companies would like to sponsor. (heh)

Plus, I forgot one major bullet point for the list.

* A more comprehensive set of tests or specs for the base library

We need *CONFIDENCE* that future releases are not going to regress in strange ways or break features that we all rely upon. I brought this up ages ago when I recommended the project bring on a testing library like cxxtest for writing unit tests in C. I even promised to write a small proof-of-concept but I broke that promise by not doing it (I'm not good enough with C and C++ to setup the g-d environment!). Maybe tonight's meetup will have some smart C/C++ guys and they can guide us on how this might be accomplished. 

Part of what makes this so frustrating is that we rely so heavily on Martin Sustrik. He knows the codebase backwards and forwards but it's hard for others to just jump in and help out. We need a way to make the code more approachable and understandable to potential contributors. My suggestion is that unit tests would be useful in that regard.

Enough! See y'all tonight.

cr