[zeromq-dev] Proposal for Z-Components in Java

Pieter Hintjens ph at imatix.com
Mon Dec 15 13:17:33 CET 2014


:-) Insomnia driven development... lol.

Nice stuff, Frederic. Expressing natural models, if possible, can
produce very useful results. I believe your classes got merged to
JeroMQ master so others will try them and comment on them.

One tip, when writing new pieces, try to always define the problem
very clearly, as otherwise you tend to get into the "making stuff"
mood, which is often hard for others to follow and measure.

In CZMQ whenever people propose large classes, we end up removing
them, for one reason or another.

On Sun, Dec 14, 2014 at 5:18 PM, Frédéric Déléchamp
<frederic.delechamp at softetic.com> wrote:
> Hello all,
>
> this is a rather lengthy message but ... I kind of promise you at least a
> good reading :)
>
> I just made a pull request into Jeromq git repo, as a proposal
> implementation for several Z-components . I have the modest ambition that
> they may be of some use for you too, and the request to give me hints and
> comments about this work and to point me to the right directions. (I know
> the hospital way, thank you)
>
> It relies on Java, but I tried to make it most readable for people not
> familiar with this language :)
>
> I tried to be as close as possible to czmq but some differences remain.
> These components are:
>
> - ZPoller : a rewriting of Poller to make more use of Java structures. It is
> event-driven enabled, customizable, inheritable without rewriting
> everything, with a possible share of resources.
>
> - ZAgent : a contract interface for safer messaging with a distant
> background service. I really am not sure about the name of this one.
>
> - ZStar: the core implementation of a distant background service and its
> user communication endpoint, with socket creation deferring to try to ensure
> their best possible use. And a "basic" contract interface. Don't take the
> code too madly, there is a "showMustGoOn" method :), but  the more I wrote
> it, the more I found the theatrical metaphor I used quite fitting the
> process. And VERY readable. And it makes the job. For once I wanted to write
> a non-boring code to re-read and fully apply what I always said to my
> students: Choose meaningful names when coding. Maybe I went too far into the
> féerie ...
>
> - ZActor: a remote controlled restartable background service
> implementation,, with a contract interface to ease separation of concerns
> between control messages and flow messages, and also have a hand on the
> keypoint's looping decision.
>
> ... and finally, using all of this ...
>
> - ZProxy: a remote controlled proxy background service with start, stop,
> pause, cold restart, customizable: hot restart, configuration requests,
> extra commands. Basic commands can be sent in sync or async mode. Also able
> to modify messages on the flow if wanted by implementing a one-method
> interface. I made most of it because I saw the possibilities and wanted to
> explore them, not because of an immediate use or need.
>
> Well at least this is their intents.
>
> If you have a look at some parts of the code, you may find it crazy at
> first, and it is my feeling as well. At least for some parts. Some renaming
> could be done as well. At least for some parts.
> Some parts I did I will not use and did not test.
>
> I got several HUGE insomnia crises these last months, and tried to express
> during these awaken periods some patterns I identified in the guide. I found
> a mental picture to describe some of them and the more I put it in
> accordance with the requirements, the more I found it didactic as well for
> readers. This is why it is in this form. And the fact that I am so tired
> that I probably (?) became berserk at some point.
>
> I tried, as an exercise of style, to make these components usable while
> delegating, composing or inheriting, or using Java-centric terminology. It
> is definitely not finished, especially the ZPoller, but I have the feeling
> they can start to fight for their existence in this form.
>
> About the differences with czmq: I had the feeling that ZPoller could make a
> good use of event dispatching without the need of a ZLoop.. When I wrote
> ZActor, I realized the more general algorithm of ZStar and decided to split
> it into 2 separate concepts. So if you don't like my ZActor proposal, ZStar
> may be still useable for your own implementation. And I discovered czmq
> zproxy AFTER writing mine. But I think this implementation covers almost all
> the spec (resume=start) ...
>
> I am interested in your comments, good or bad. For the "crazy" one, I
> repeat: I am aware of that.
>
> I also have some motivations to expose you this work: I have a very
> interesting project but a severe deprivation of sleep, and if you could help
> me to perfect these components or find some replcament so I could focus
> later back on my main project , I would be very glad.
>
> ... I really need some rest now. I will come back later.
>
> Thanks for the time you have taken to read this. Hope you will find some
> time as well to read my code!
>
> Have a nice time with your families!
>
> PS: I am french so I used some expressions of my language instead of the
> english ones.
>
> --
> Frédéric Déléchamp
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list