add high-level binding Layer

[Ccccraz]

We need some advanced features that are not directly provided by JeroMQ, such as recvMultiparts(), pollin(), etc. However, the current implementation mixes high-level binding and the wrapper layer. For example, for methods like pollin() in +jzmq/+ZMQ/Poller.m, in fact, JeroMQ provides functions with the same name but different functions, such as: JeroMQ ZMQ.Poller.pollin()

I think we should keep the purity of the wrapper layer and maintain consistency with JeroMQ. Therefore, I think it is necessary to create a high-level binding layer.

At present, our project structure is:

.
├── +jzmq
│   ├── +ZMQ
│   │   ├── Poller.m
│   │   ├── PollerEvent.m
│   │   └── Socket.m
│   ├── jeromq-0.6.0.jar
│   ├── PollEvent.m
│   ├── SocketType.m
│   ├── ZContext.m
│   └── ZPoller.m
├── LICENSE
└── README.md

I think we can try to modify it to:

.
├── +jzmq
│   ├── +matlabZMQ
│   │   └── MSocket.m
│   ├── +ZMQ
│   │   ├── Poller.m
│   │   ├── PollerEvent.m
│   │   └── Socket.m
│   ├── jeromq-0.6.0.jar
│   ├── PollEvent.m
│   ├── SocketType.m
│   ├── ZContext.m
│   └── ZPoller.m
├── LICENSE
└── README.md

or

.
├── +matlabZMQ
│   └── MSocket.m
├── +jzmq
│   ├── +ZMQ
│   │   ├── Poller.m
│   │   ├── PollerEvent.m
│   │   └── Socket.m
│   ├── jeromq-0.6.0.jar
│   ├── PollEvent.m
│   ├── SocketType.m
│   ├── ZContext.m
│   └── ZPoller.m
├── LICENSE
└── README.md

Add something similar to +matlabZMQ (I think the name needs to be considered, perhaps +matlab-jzmq is better) for high-level binding

[iandol]

JeroMQ has 3 levels: close to libzmq (zmq.) -- then intermediate in the org.zeromq.ZMQ. code and then higher level like org.zeromq.ZPoller. But nothing is really pure (even zmq* is not just a pure mirror of libzmq but has changes). If you take the ZMQ.Socket it has many many methods:

https://www.javadoc.io/static/org.zeromq/jeromq/0.6.0/org/zeromq/ZMQ.Socket.html

Including methods for multiframe messages (sendMore, hasReceiveMore) to automate multiframe sending of images (recvPicture) or messages (recvMsg) and lots of other methods. My feeling is JeroMQ itself is not at all pure, it has a very busy method list to make it functional. If we want a pure interface we should support these methods... For pollin / pollout in fact those methods are specified and are what I infer my pollin and pollout: https://www.javadoc.io/static/org.zeromq/jeromq/0.6.0/org/zeromq/ZMQ.Poller.html#pollin(int)

JeroMQ is already messy. If you want it pure and at the level of ZMQ.* it should contain pollin, sendMore / Msg and the other methods. Or we can just tailor it to our needs. I don't strongly mind, but my preference is functional, methods that we will use, not the 100 methods in ZMQ.* we won't nor multiple namespaces.

[Ccccraz]

I also think we should carry out progressive development based on JeroMQ and don't need to wrap all JeroMQ methods.

Indeed, JeroMQ is already quite messy. I don't want to introduce more problems. Including the methods we need in +jzmq should be solve this problem.

However, I still believe that for the existing methods from JeroMQ, what we should provide is a simple wrapper rather than changing its functionality. I think this would bring more confusion. When problems occur, we need to spend more effort on debugging. But if the wrapper is simple, we can almost immediately tell whether the problem comes from JeroMQ or our code.

So my current idea is to keep the existing structure, add the advanced features we need to a location similar to +ZMQ.Socket.m, and maintain a simple wrapper for the original methods, such as:

% ZMQ.Socket.m
function register() %simple wrapper
end

function poll() %simple wrapper
end

function pollin() %simple wrapper
end

function pollInEvent() %our new method
    obj.register();
    obj.poll();
    ... some logic
end

[iandol]

OK, refactor as you think is best 👍🏼 — for the namespace not sure, +jzmq does not exist in JeroMQ, it is sort of equivalent to org.zeromq — I'd prefer something inside +jzmq so there is only one base namespace. You suggested +jzmq.matlabZMQ.mSocket or something similar (don't need to keep repeating zmq so it could be +jzmq.matlab.MSocket). An alternative is use +jzmq directly like +jzmq.MSocket or +jzmq.MATLABSocket given thet jzmq does not exist in JeroMQ anyway. Either is fine.

[Ccccraz]

Okay, I will create a new branch for refactoring.

Just as you suggested, I won't introduce new namespaces like +matlab_jzmq or .m files like +jzmq.MSocket anymore. Instead, I'll introduce named functions with identifiers to achieve this.

example:

% ZMQ.Socket.m
function register() %simple wrapper directly from JeroMQ
end

function poll() %simple wrapper directly from JeroMQ
end

function pollin() %simple wrapper directly from JeroMQ
end

function mPollIn() %The advanced features we need are prefixed with m.
    obj.register();
    obj.poll();
    ... some logic
end

However, I'm not sure about the naming style of the function. It could be Mpollin(), mPollIn, MPollEventIn(). What's your recommendation?

[iandol]

I prefer camelCase, so mPollIn() for example. JeroMQ mostly uses PascalCase but Java itself uses camelCase so camelCase seems better overall...