[R-gui] Interfaces between GUIs and R

[Byron Ellis]

On Thursday, April 3, 2003, at 09:02  AM, Duncan Temple Lang wrote:

> As you know, I have been working on connecting many systems with R
> (e.g. Perl, Python, Java, Octave, XLisp, S-Plus, ...), and have been
> trying to get across that using strings across systems is quite
> limiting for general computations.  Direct embedding, COM/CORBA, SOAP

Yep, thats why I made sure you were on the R-gui roles when I sent the 
message. otherwise you would have been CC'd  ;-)

> or our own version of an XML format for Stat objects seems to be an
> obvious collection of approaches.  Robert and I put together much of
> an RSXMLObjects package which serializes and reads arbitrary S objects

I had forgotten about RSXMLObjects

> (including language objects, etc.) using an XML format.  The
> structures can be easily extended (in the XML sense) to support other
> languages.

I saw that stuff as well as SSOAP, though I couldn't figure out if the 
latter actually provided a server mechanism. The problem with 
SOAP/XMLRPC that I see so far is a lack of state, since the kernel 
paradigm is generally taken to be stateful and, I think, for good 
reason: if you have some long running calculation you don't really want 
to repeat the entire calculation because you forgot to change the title 
of a graph (in Sweave, for install, anything long running I tend to run 
separately to avoid having it run in the weave portion). Sure, we could 
implement state using session IDs and whatnot, but it seems like an 
awful lot of work just to use the current "hot" XML structure. An XML 
stream would seem more appropriate, except that XML isn't really 
conducive to streaming---it is a document format after all-- and is 
awfully verbose, especially if we start passing complex graphs around 
(isomorphic to the PS vs. PDF argument I guess)

>
> If the set of kernels is known and fixed, creating a new or
> non-standard protocol is fine.  If people are likely to want to add
> new kernels, they would then have to implement that protocol.  Using
> something like CORBA/COM, SOAP or embedding would increase the chances
> of that person being able to use existing facilities in that kernel.

Well, in this case the kernel is R. :-) However, protocol aside (in 
some sense the exact protocol is secondary) there are a variety of 
things that are sort of general to the kernel execution universe. For 
instance, separate execution spaces for sessions--- if I have two 
documents I don't really want execution in one document to affect the 
other documents because thats just weird and liable to trip people up 
since they are visually separate documents. Having multiple 
interpreters around would solve this since they would live in their own 
spaces, but launching multiple copies of R (one for each document and 
since the session has state R basically has to hang around for as long 
as the document is open) is going to get really expensive. Multiple 
interpreters within R would be nice (I'm not talking about 
multithreading, just the ability to run multiple 
interpreters---something I seem to recall Robert mentioning a year or 
so ago) but would likely involve moving a goodly ways towards thread 
safety--or at the very least passing the interpreter structure to all 
the functions, breaking everything. :-) At the moment, there may be a 
way to hack this behavior using environments, but I suspect people 
could still break the paradigm (either intentionally or inadvertently) 
with relative ease. I'm sure there are other issues as well :-) (like a 
graphics device that exposes the display list to R s.t. it can be 
serialized from whatever communication protocol you desire... except 
for the font metrics, this would be fairly straightforward... would we 
need the font metrics to just record the display list? I'm not sure)

Basically, a lot of the same stuff you work on :-)

>
>  D.
>
> Byron Ellis wrote:
>> Hi folks, this is a question for all you GUI developers out there
>> though, in particular, to those who work on SciViews and RKward 
>> (though
>> anyone else is certainly welcome to chime in). Presently, my StatPaper
>> app (which will have a website soon, I've just been busy this week) 
>> and
>> AFAIK RKward employ a "kernel"-type interaction method (SciViews
>> mentions a kernel, but I haven't been able to test it to see how it
>> works) with R, that is R itself runs as a separate process and
>> communication takes place over either the STDIN/STDOUT associated with
>> the process or through some other means (say, UNIX sockets).  This
>> works fine if we're just passing text back and forth, but when we want
>> to start passing objects or graphics device information things start 
>> to
>> do downhill pretty quickly.
>>
>> My question: Is there any interest in developing a general kernel
>> interaction protocol for R GUIs? This would most likely include the
>> following:
>> 	* Representation of data objects
>> 	* Execution of R statements
>> 	* Returning graphics of the kernel link
>> 	* ???
>>
>> Recently, I've been looking at the OpenMath protocol
>> (http://www.openmath.org) for use in StatPaper and it seems fairly
>> simple and robust. It bears a great deal of resemblance to the 
>> MathLink
>> protocol employed by Mathematica. At the moment I think this entire
>> thing could be done as an R package, possibly using the REventLoop
>> mechanism for the server (though I don't know that it would be
>> necessary) and also providing client access so that two R 
>> installations
>> could communicate (I know that Rpvm and Rmpi already exist, though 
>> they
>> have a somewhat different goal) in a standard fashion if desired.
>>
>>
>> Byron Ellis (bellis at hsph.harvard.edu)
>> "Oook" - The Librarian
>>
>> _______________________________________________
>> R-SIG-GUI mailing list
>> R-SIG-GUI at stat.math.ethz.ch
>> https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui
>
> -- 
> _______________________________________________________________
>
> Duncan Temple Lang                duncan at research.bell-labs.com
> Bell Labs, Lucent Technologies    office: (908)582-3217
> 700 Mountain Avenue, Room 2C-259  fax:    (908)582-3340
> Murray Hill, NJ  07974-2070
>          http://cm.bell-labs.com/stat/duncan
>
Byron Ellis (bellis at hsph.harvard.edu)
"Oook" - The Librarian