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/public/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]]

