[zeromq-dev] zproto and Malamute/Majordomo

[Pieter Hintjens]

In general zproto is aimed at binary framing that changes very rarely.
This is excellent for protocols like filemq, ZRE, or Malamute. It's
often poor for application RPC protocols.

You can easily adapt the zproto generators; they are plastic and
easily user-customizable. You do need to learn basics of the GSL
language, which is straight-forward. In general as Joe says, code
generation is a good tool to know.

This doesn't exclude adding (back) the encode/decode API to zproto so
it can work on top of Malamute, Zyre, etc.




On Tue, Apr 28, 2015 at 5:10 AM, Joe McIlvain <joe.eli.mac at gmail.com> wrote:
> Lucas,
>
> It may well be that code generation is a good choice for solving your
> problem but zproto (one specific set of code generators) is not.  You can
> always use GSL to write your own code generator scripts that are verbose and
> descriptive.  Codecs generated by zproto are not all verbose or descriptive.
>
> On Mon, Apr 27, 2015 at 7:54 PM, Lucas Russo <lerwys at gmail.com> wrote:
>>
>> Pieter Hintjens <ph <at> imatix.com> writes:
>>
>> >
>> > My personal view on this is that zproto is ideal for underlying
>> > protocols, whereas application protocols (such as you'd carry over
>> > Malamute) should use a cheaper text format.
>> >
>> > This is the Cheap and Nasty discussion in the Guide. Zproto being the
>> 'nasty'.
>> >
>> > On Mon, Apr 27, 2015 at 7:13 PM, Pieter Hintjens <ph <at> imatix.com>
>> wrote:
>> > > It's been done, and removed from the basic codec generator. You can
>> > > see how this was done in zproto_codec_c_v1.gsl.
>> > >
>> > > There has been talk of adding this encode/decode support back in to
>> > > the
>> C codec.
>> > >
>> > > On Mon, Apr 27, 2015 at 3:56 PM, Lucas Russo <lerwys <at> gmail.com>
>> wrote:
>> > >> Hello everybody,
>> > >>
>> > >> I'm taking a look at zproto project, in order to better structurize
>> and
>> > >> document an application protocol.
>> > >>
>> > >> However, is there a way to use zproto on top of, for instance,
>> malamute or
>> > >> majordomo API? Meaning defining my application protocol with zproto,
>> but
>> > >> sending/receiving messages using malamute or majordomo?
>> > >>
>> > >> As far as I understood zproto uses the regular czmq API to send/recv
>> > >> messages, but malamute and majordomo both have different APIs to
>> send/recv,
>> > >> like mlm_sendx () and mdp_client_send ().
>> > >>
>> > >> Regards,
>> > >>
>> > >> Lucas
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> zeromq-dev mailing list
>> > >> zeromq-dev <at> lists.zeromq.org
>> > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> > >>
>> >
>>
>> Hi Pieter, Thanks for your answer,
>>
>> I see. But without zproto support for this kind of thing, wouldn't my only
>> option be to document, structurize and serialize the message myself?
>>
>> Also, from the guide, the 'cheap' part of the pattern should be
>> "synchronous, verbose, descriptive, and flexible". Isn't this a good use
>> case for a tool to generate codecs for us automatically? So, we would end
>> up having a very descriptive and verbose protocol?
>>
>> Maybe I misunderstood something, but zproto seemed like a suitable choice
>> to my needs. Is there something very flawed in this reasoning?
>>
>> Thanks and Regards,
>>
>> Lucas
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>