Moved ZMQServer to org.micromanager.internal

[henrypinkard]

Still starting ZMQServer from Magellan plugin loading. Where is the appropriate place to start it after its been added to tools--options?

[nicost]

I started working on integrating this in branch zmq (https://github.com/nicost/micro-manager/tree/zmq). The bridge could be started in MMStudio during start-up. There should be a function in MMStudio (later possibly also in the api itself, i.e. in Studio) that gives access to the bridge. If bridge startup is fast, we can even wait to create the bridge until someone asks for the bridge.

We do need to remove all references to Magellan in org.micromanager.internal.zmq. I do not yet understand the code well enough to know how to go about this. Suggestions?

[nanthony21]

This is great to see. I was just thinking about adding ZeroMQ to a plugin that I use, but maybe I can make use of these classes once they're merged. I see some things that should probably be changed though.

• ZMQClient and ZMQAcquisitionHookClient are commented out. Maybe the files should just be removed.

• All the files should probably have the default header replaced with a license.

• Would it be possible to implement some way for external code to register an API with the server? This would allow for the removal of all the hardcoded references to Magellan.

• In general a bit more commenting to explain each method would be helpful in the future.

[henrypinkard]

@nicost I will pull that branch and look through it.

@nanthony21 Thanks for the suggestions. With the caveat that I don't know what you mean by "adding ZeroMQ to a plugin", I'm not sure how useful these classes will be to you. These are meant to be internal, and will not expose a user facing API for some time (if ever) as I continue to change them. They are meant to be used in conjunction with a package for controlling Micro-manager/magellan from Python (https://github.com/henrypinkard/Pygellan).

If you're looking to use ZeroMQ, there is already a library for that (JeroMQ) included with nightly builds of MMGamma. Alternatively, if you're looking to control MM through Python, these are an implementation detail that is not necessary to know about.

[nicost]

@henrypinkard I do hope that this code will become generally usable, and a "general" bridge to the outside world (mainly python) that can be used from multiple places, and it would be great to add this to the api as soon as we have a good concept going. It may be too early, but it would be good to develop the code with that goal in mind.

I guess that Nick'2 3d point could be helpful in removing references to Magellan. Or do we want to try to register everything that is on the classpath?

[nanthony21]

@henrypinkard I think the case I have in mind is similar to the case of Magellan. I have a custom Micro-Manager plugin which handles our data acquisition. I also have a project in Python that handles our data analysis. I'd like like to allow the two sets of code to talk to eachother via ZeroMQ.

Of course, I could do this by writing all the necessary JeroMQ code in my plugin and not rely on anything from org.micromanager, and it may turn out that is what I'll need to do.

However, the main point is that for organizational purposes, if this code is being migrated into the org.micromanager.internal package then it should probably be generic enough to not have any hard-coded dependency on other, more specific packages, such as org.micromanager.magellan.

[henrypinkard]

@nanthony21 Ah okay I see. In that case I think Pygellan will work for you (see this issue). I will add a mechanism for adding classpaths manually or registering all of them after I get a chance to experiment a bit