No real hurry as we've made a hand-coded JNI wrapper that works sufficiently for the demo we wanted to make.
Something to chew on. Thanks for the input. On Thu, Sep 10, 2015 at 10:33 AM, Joe McIlvain <[email protected]> wrote: > Pieter, > > I don't think the issues with sharing types from other zproject-projects has > been solved at all yet. > > The main difficulty is that the CZMQ API XML models will not be loaded at > the time you are loading the Zyre API XML models. The way the workflow > works right now, these are two separate sessions of GSL generation - the > CZMQ session and the Zyre session. One solution for this might be to > install the XML files when installing the library, then dependent libraries > can look for these in some standard location. You'd probably also need a > way to manually specify where GSL should look first if, for example, you > want to generate against a different version of CZMQ than you have > installed. I think this has the potential to be a robust solution, but > needs careful design. > > When I was doing a slew of private zproject-based work (and I wish I was > still doing it right now, because it was quite enjoyable development), I had > another plan in my head to use when I needed it for the primitive CZMQ > types. I was going to hard-code the basic CZMQ types (like Trevor Bernard > suggested) into zproject, so that it always recognized how to translate a > zmsg for example into an array of strings. This is kind of a hack more than > a solution, as it is brittle and tied to a specific interface provided by > CZMQ, which we'd have to find a way to change if the CZMQ interface for > those types changed. Overall, a solution like the previous paragraph > suggests would be more ideal, but has its own difficulties as well. > > In my projects, I ended up avoiding this by simply making sure I didn't need > to accept or return any CZMQ types in the interfaces of my classes, only > primitive types like strings and numbers. This works well if you are > designing the classes from scratch to be used in this situation, because you > can create whatever abstractions you need to acheive this. In the case of > Zyre where the interface is already stable, this is probably not helpful, > though. > > Feel free to ping me on IRC if you have any pressing real-time questions > (since you mentioned you were in a hurry). > > On Thu, Sep 10, 2015 at 5:35 AM, Pieter Hintjens <[email protected]> wrote: >> >> Adam, I think what we missed is that we have to JNIify CZMQ first, and >> then we can use that in Zyre. The alternative, which Trevor suggested, >> is manual workarounds for the CZMQ classes. >> >> On Thu, Sep 10, 2015 at 8:31 AM, Wynne Adam (CR/RTC3.1-NA) >> <[email protected]> wrote: >> > Hi Joe, >> > >> > >> > >> > We could also use help with the implementation of the internals. You >> > can >> > see that I started this in my original commit but got stuck managing the >> > poller_wait to make recv() work. >> > >> > >> > >> > Best regards >> > >> > Adam Wynne >> > CR/RTC3.1-NA >> > >> > Tel. +1(412)390-3211 >> > >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of Joe McIlvain >> > Sent: Wednesday, September 09, 2015 11:45 PM >> > To: ZeroMQ development list <[email protected]> >> > Subject: Re: [zeromq-dev] JNI binding generation >> > >> > >> > >> > Pieter, >> > >> > When you say you're stuck on the internal model, do you mean on the >> > zproject >> > representation of the API model, or on JNI-specific internals (in need >> > of a >> > Java/JNI guru)? >> > >> > >> > >> > On Wed, Sep 9, 2015 at 2:11 PM, Pieter Hintjens <[email protected]> wrote: >> > >> > Hi guys, >> > >> > We've started a small effort to make a JNI binding generator in >> > zproject, with Zyre as our use case. >> > >> > We're getting a little stuck on the internal model, so if anyone wants >> > to lend a hand, the code is on zproject master in >> > zproject_bindings_jni.gsl. >> > >> > Cheers >> > Pieter >> > _______________________________________________ >> > zeromq-dev mailing list >> > [email protected] >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> > >> > >> > >> > _______________________________________________ >> > zeromq-dev mailing list >> > [email protected] >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
