Sure, that makes perfect sense. Socket-based IPC is commonly used for
controlling applications from other environments, for reasons of
simplicity.
Every language has access to sockets. Then again, all popular
languages have
JNI-based bridges to Java.
I once wrote a R <-> Java bridge based on SOAP, but was disappointed
with
its performance in highly interactive applications. It all depends on
the
use case, I guess.
Michael
On Fri, Jul 16, 2010 at 1:01 PM, Jan Bot <j.j.bot@tudelft.nl> wrote:
>
> Hi,
>
> for us one of the main concerns was that we wanted to be able to
access
> Cytoscape from different programming languages, that is why we chose
XML-RPC
> for our plug-in. I guess you'll have to give that up when
implementing your
> solution.
>
> Jan
>
>
> On 07/16/2010 07:24 PM, Michael Lawrence wrote:
>
>
>
> On Fri, Jul 16, 2010 at 7:43 AM, Paul Shannon
<pshannon@systemsbiology.org> > wrote:
>
>> Hi Michael,
>>
>> Thanks for your comments.
>>
>> In an earlier version of a bridge between Cytoscape & R I used an
approach
>> much like you suggest: I used RJava and RMI. Two problems kept
cropping
>> up. First, linux users (and sometimes others) often reported a lot
of fuss
>> installing RJava; perhaps SJava would have been better. Second,
though RMI
>> allowed Cytoscape & R to run loosely coupled, the connection was
fragile,
>> and both programs had to be restarted if the connection was lost.
>>
>> With XML-RPC, we seem to have the best of both worlds: control of
>> Cytoscape as if it and R were running in-process; robustness when
the
>> connection gets lost, or if either program is shut down. I admit
to a bias
>> towards loose coupling. Tying two complicated programs tightly
together
>> scares me a bit.
>>
>> That said, your suggestion of a two-tiered interface is intriguing.
Could
>> your elaborate on "more control could be gained through direct
embedding"?
>> What kinds of control are you thinking of? I would be glad to
consider
>> this.
>>
>>
> I guess it's just that in my workflows I rarely need R and Cytoscape
> running in a separate process. I'll usually have R running and then
want to
> fire up a visualization. Or have the external application embed R to
> generate some statistics. Direct embedding means to simply call the
main()
> function of Cytoscape from R. Then just call the Cytoscape Java API.
I made
> an unreleased package that used this to load a network from an R
graph
> object and configure the visual mapping in Cytoscape.
>
> My assumption is that Cytoscape has a sufficiently stable API that
> minimizes concerns with coupling. Might be good to have an
abstraction on
> the R side, so that other network programs could be integrated
> transparently. Like what was done for genome browsers with
rtracklayer.
>
> Michael
>
>
>
>> Thanks!
>>
>> - Paul
>>
>>
>> On Jul 16, 2010, at 5:02 AM, Michael Lawrence wrote:
>>
>> > Hi Paul,
>> >
>> > This is cool stuff. I'm wondering why you went with the XML-RPC
approach
>> as opposed to direct embedding via e.g. SJava? I guess it's a pure
R
>> solution, without worrying about technical complications from the
R-Java
>> bridge. Do you envision running Cytoscape and R in two separate
processes?
>> >
>> > I could see a two-tiered interface, with simple commands
depending only
>> on the RPC interface, while more control could be gained through
direct
>> embedding via the JNI, if the user wanted to deal with the
complications.
>> >
>> > Michael
>> >
>> > On Thu, Jul 15, 2010 at 7:33 PM, Paul Shannon <
>> pshannon@systemsbiology.org> wrote:
>> > Building upon some exemplary work by Jan Bot (the CytoscapeRPC
plugin)
>> and Duncan Lang (XMLRPC package) we now have a good start on
controlling
>> Cytoscape 2.7 from R.
>> >
>> > Much remains to be done. Once this version gets some mileage on
it, I
>> will convert its current procedural style into proper S4 classes,
and submit
>> the package to Bioconductor.
>> >
>> > The biggest deficit in the package that I am aware of occurs in
sending
>> large graphs from R to Cytoscape take longer than it should. Some
tuning of
>> XMLRPC may be needed to fix this.
>> >
>> > All the code (the Cytoscape plugin, the XMLRPC package (with some
of my
>> own modifications) and the new CRytoscape package) can be found
here:
>> >
>> >
>>
http://db.systemsbiology.net:8080/cytoscape/gaggle/test/cy2rpc/publ
ic/index.html
>> >
>> > Lots of documentation is provided, as well as a test script which
>> demonstrates how to use the package.
>> >
>> > Suggestions, complaints, rants and bug reports are all welcome.
>> >
>> > - Paul
>> >
>> > _______________________________________________
>> > Bioconductor mailing list
>> > Bioconductor@stat.math.ethz.ch
>> >
https://stat.ethz.ch/mailman/listinfo/bioconductor
>> > Search the archives:
>>
http://news.gmane.org/gmane.science.biology.informatics.conductor
>> >
>>
>>
>
>
[[alternative HTML version deleted]]