AW: [R-gui] Interfaces between GUIs and R

TB thomas.baier at kirchnersoft.com
Fri Apr 4 14:49:00 MEST 2003


Philippe,
Byron,

> -----Ursprüngliche Nachricht-----
> Von: Philippe Grosjean [mailto:phgrosjean at sciviews.org]
> Gesendet: Donnerstag, 03. April 2003 09:11
> An: Byron Ellis
> Cc: R-sig-gui at stat.math.ethz.ch
> Betreff: RE: [R-gui] Interfaces between GUIs and R
> 
> 
> 
> 				R COM Server	SciViews R Plug
> communication		synchronous		asynchronous
> client implementation	easy (5 methods)	more difficult
> (callbacks,...)
> speed of execution	++			+
> interruptible calc	no			yes
> friezes the client(*)	yes			no
> concurrent kernels(**)	no			yes
> 
> (*)  A single threaded client must wait for the completion of the
> calculation with synchronous evaluation, while it can process other code
> during evaluation with an asynchronous evaluation
> (**) As a consequence, an asynchronous evaluation allows simultaneous
> evaluation in different kernels (some kind of parallelization), while
> with a
> synchronous evaluation one can connect to several kernels, but must
> serialize evaluations in these different kernels.

Please let me add some clarifications:

1. Concurrent kernels are also supported by R COM Server.
2. Concurrent evaluation of different expressions in different kernels
   is also supported, but one has to do the asynchronous processing by
   using different threads/processes in the application program. While
   on expression is evaluated, the COM server blocks. But the COM server
   does not restrict your client application to a single thread.
3. Different kernels on the same or on different machines can be utilized
   the same time by the COM server. I assume, this also holds true for
   SciViews.

> As a conclusion, I consider R COM Server as a fast and simple interface
> to
> R, but it has some limitations, like client friezing, uninterruptible
> calculations, and no concurrent evaluations in differents kernels that
> makes
> it less suitable for a complete GUI client. The SciViews R Plug is more
> designed towards this goal.

Philippe, as we discussed in Vienna, this depends on the requirements and
is just where we are of different opinions. I prefer to have a
multi-threaded
client application, where I have full control over my parallel threads of
execution and don't want to take care of asynchronously running R kernels.

Best,
Thomas



More information about the R-SIG-GUI mailing list