[zeromq-dev] When unreliability is desired

[Lindley French]

Come to think of it, the way that library is structured, it would be easy
enough to use it on top of ZMQ. Therefore it may not be reasonable to
integrate it anyway.


On Wed, Dec 18, 2013 at 2:31 PM, Lindley French <lindleyf at gmail.com> wrote:

> >Yes, many reasons. The main one is complexity. You can read
> >http://hintjens.com/blog:19 and our contribution process, RFC 22,
> >which requires that every patch be a minimal solution to an agreed
> >problem. Importing libraries breaks that rule and needs to happen with
> >great care when we're sure the tradeoffs are worth it.
>
> Whether or not FEC functionality is needed is the relevant question. If
> that is agreed to be a problem, whether the solution comes from a library
> or new code is a separate issue.
>
>
> >Technically, additional dependencies make packaging ZeroMQ a horrid
> process.
>
> Large dependencies, sure. Small dependencies that can be added just as a
> few additional source files (license permitting) shouldn't be a big deal.
>
> >If you can solve whatever problem you have without using ZeroMQ, why
> >would you use ZeroMQ?
>
> The same reason I use any library---to save time, and effort, and because
> I understand that there's no point reinventing the wheel if someone already
> has functionality I can leverage in a tested, working condition.
>
>
> On Wed, Dec 18, 2013 at 2:05 PM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> On Wed, Dec 18, 2013 at 7:22 PM, Lindley French <lindleyf at gmail.com>
>> wrote:
>>
>> > Any particular reason? The natural extension of that philosophy is that
>> I
>> > shouldn't bother looking at ZeroMQ because it's an existing library and
>> I
>> > might be able to solve my problems other ways.
>>
>> Yes, many reasons. The main one is complexity. You can read
>> http://hintjens.com/blog:19 and our contribution process, RFC 22,
>> which requires that every patch be a minimal solution to an agreed
>> problem. Importing libraries breaks that rule and needs to happen with
>> great care when we're sure the tradeoffs are worth it.
>>
>> Technically, additional dependencies make packaging ZeroMQ a horrid
>> process.
>>
>> If you can solve whatever problem you have without using ZeroMQ, why
>> would you use ZeroMQ?
>>
>> -Pieter
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131218/b5e71d22/attachment.htm>