Hi Josh,<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex" class="gmail_quote">Was your and Mario's primary goal to get away from the in-process issues
of the JVM? Would it be an option to fork, create the JVM, and then use
Ice rather than raw sockets for the communication? In that case would
you need all objects? Or does the API that Mario is already using come
close to sufficing? What are the other features/requirements that need
to be added?<br></blockquote>
<br>I believe the goal was to have an inter-process solution to decouple the JVM a bit from the C++ program. However, I admit that I am fuzzy on the specifics of why Mario wants an inter-process solution. In his talk, he mentioned one problem with allocating memory to the JVM a priori, and how to deal with OutOfMemoryError, but I am not clear on why an inter-process solution would improve on that situation. Mario, any comments?<br>
<br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex" class="gmail_quote">Curtis, I assume your plan is to turn everything into an Ice Prx? e.g.
would you have an IRandomAccessPrx? If so, I'm skeptical that this would
work as well as you want.<br></blockquote><br>Yep, everything would be exposed as proxies. So sure, there would be an IRandomAccessPrx, but it's not like most consumers of the API would actually make use of it (since I agree, it would be awful performance-wise). Most people would interact with the Java library at a less fine-grained level—e.g., calling IFormatReader.openBytes to grab one plane at a time. There is still overhead at that level, but much less.<br>
<br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex" class="gmail_quote">I can't remember the specific problem we were having, Curtis. To you
have that email still and/or link on ome-devel? I found only <a href="http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2010-October/001733.html" target="_blank">http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2010-October/001733.html</a><br>
</blockquote>
<br>I couldn't find it on the mailing list either; perhaps we discussed it over chat.<br><br>To understand the problem again after so long, I mocked up a Slice interface for a small subset of the Bio-Formats API. In so doing, I found the solution to the previous issue on this page of the Ice manual:<br>
<br> <a href="http://doc.zeroc.com/display/Ice/Object+Incarnation+in+Java">http://doc.zeroc.com/display/Ice/Object+Incarnation+in+Java</a><br><br>To describe briefly, say we have the following Slice definition:<br><br> interface CoreMetadata;<br>
interface IMetadata;<br> interface IFormatReader {<br> CoreMetadata* getCoreMetadata();<br> IMetadata* getMetadataStore();<br> };<br><br>When implementing servants on the server side, you must implement methods that return proxies of other servants; e.g.:<br>
<br> public CoreMetadataPrx getCoreMetadata(Current current);<br>
public IMetadataPrx getMetadataStore(Current current);<br><br>I was stumped on how to translate a server-side Java object into a proxy of a servant that wraps that object. The solution (from the Ice page linked above) is:<br>
<br> CoreMetadataPrx proxy = CoreMetadataPrxHelper.uncheckedCast(<br> current.adapter.addWithUUID(new CoreMetadataI(coreMetadata)));<br><br>(Assuming that the CoreMetadataI servant implementation has a constructor that takes a CoreMetadata object, of course.)<br>
<br>Personally, I would describe that invocation as "horribly unintuitive" and perhaps "needlessly complex" (why not "current.adapter.createProxy(new CoreMetadataI(coreMetadata))"), but at least there is a way to do it!<br>
<br>I have posted my full solution at:<br>
<br> <a href="http://dev.loci.wisc.edu/curtis/bf-ice/">http://dev.loci.wisc.edu/curtis/bf-ice/</a><br><br>There are shell scripts for launching the server and the client, and a small test to verify that information is being communicated properly. All works, so I think my proposal to autogenerate a Slice file from a Java JAR file is doable. The only question is: when will I find the time?<br>
<br>Regards,<br>Curtis<br><br><div class="gmail_quote">On Tue, Jun 21, 2011 at 7:12 AM, Josh Moore <span dir="ltr"><<a href="mailto:josh@glencoesoftware.com" target="_blank">josh@glencoesoftware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jun 17, 2011, at 11:17 AM, Curtis Rueden wrote:<br>
<br>
> Hi everyone,<br>
<br>
Hi,<br>
<div><br>
> Yesterday Mario Emmenlauer and I discussed the Bio-Formats Ice bindings, and<br>
> how it would be nice to resurrect them so that Bio-Formats has an<br>
> inter-process, cross-language integration solution.<br>
><br>
> I started looking at how best to resurrect them. The way they were being<br>
> done before was very ad hoc. We generated them from a Velocity template that<br>
> was quite hard-coded in many ways compared to the way the way the C++<br>
> bindings work. See:<br>
><br>
><br>
> <a href="http://git.openmicroscopy.org/?p=bioformats.git;a=blob;f=components/autogen/src/ice/bio-formats.vm;hb=HEAD" target="_blank">http://git.openmicroscopy.org/?p=bioformats.git;a=blob;f=components/autogen/src/ice/bio-formats.vm;hb=HEAD</a><br>
><br>
> In contrast, the C++ bindings wrap every method of every Java class in<br>
> bio-formats.jar, loci-common.jar and ome-xml.jar.<br>
><br>
> We could do something similar for the Bio-Formats Ice bindings—generate a<br>
> Slice file mirroring the Bio-Formats API as fully as possible—but it would<br>
> require a bit of work. And of course it results in a very granular remoting<br>
> API compared to how people often use Ice. Nonetheless, it would make for an<br>
> intuitive API, as long as people exercise some care not to make too many<br>
> remote calls as Mario mentioned in his XuvTools talk yesterday.<br>
><br>
> Do others agree that such a thing would be useful? If so, I am thinking<br>
> about how best to implement it. My initial inclination is to write some Java<br>
> code that takes a JAR file as input, and generates a Slice file with<br>
> interfaces mirroring each class in the JAR, as well as the Java server<br>
> implementation code that simply delegates to the wrapped JAR.<br>
<br>
</div>Was your and Mario's primary goal to get away from the in-process issues of the JVM? Would it be an option to fork, create the JVM, and then use Ice rather than raw sockets for the communication? In that case would you need all objects? Or does the API that Mario is already using come close to sufficing? What are the other features/requirements that need to be added?<br>
<div><br>
> My questions, mostly to those who know more about Ice, are:<br>
><br>
> 1) Is there already a tool out there for doing this? Or a better way in<br>
> general?<br>
<br>
</div>None that I know of.<br>
<div><br>
> 2) Are there any roadblocks you can foresee with this approach, aside from<br>
> bad performance in some cases?<br>
<br>
</div>Curtis, I assume your plan is to turn everything into an Ice Prx? e.g. would you have an IRandomAccessPrx? If so, I'm skeptical that this would work as well as you want.<br>
<div><br>
> One potential roadblock: years ago I had trouble with methods of one<br>
> interface returning objects of a different interface. At the time, Josh<br>
> Moore and I concluded that it was sort of infeasible to have these sorts of<br>
> methods. E.g., IFormatReader.getCoreMetadata() returns a CoreMetadata<br>
> object, but this is difficult to implement properly in the server-side<br>
> implementation due to how Ice proxies work. But my intuition is that there<br>
> may be a clever workaround...<br>
<br>
</div>I can't remember the specific problem we were having, Curtis. To you have that email still and/or link on ome-devel? I found only <a href="http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2010-October/001733.html" target="_blank">http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2010-October/001733.html</a><br>
<br>
> Thoughts welcome!<br>
> -Curtis<br>
<br>
Cheers,<br>
<font color="#888888">~Josh</font></blockquote></div><br>