[Rd] Bridging R to OpenOffice

[Leonard Mada]

Hi.

Indeed, there is still some time left before the students get allocated. 
Though I would like to have various issues already analysed before the 
actual coding starts (me already drawing a tough schedule for the 
students ;-) ).

Some projects are OK when you simply start to write code and refine it 
later. I often favour such an approach, too.

But I feel this one is much to important for such an approach and there 
are surely many issues where clever ideas and solutions would make a 
difference.

1. I am still unsure of many of these issues. One involves importing the 
data back from R (as Prof. Neuwirth pointed out). Unfortunately OOo Calc 
does only have simple data structures (numbers, date, strings and 
formulas) and NO complex objects. More complex objects would be helpful 
(having various methods, like a summary - what to display in the cell, 
and also various built in functions interpreting only some subvalues of 
it). I will probably address this issue on the Calc development list 
(though this one would be difficult to implement, too).

2. As there is interest in this discussion, should we move back to the 
devel-list?

Sincerely,

Leonard


Prof Brian Ripley wrote:
> Quick comments:
>
> 1) I had intended to mention Java, as I believe Oo uses that on the 
> database side. I tend to struggle with Java (e.g. it is only recently 
> working with JNI on my main platform, AMD64 Linux).  Simon Urbanek and 
> Duncan Temple Lang are our Java gurus.
>
> 2) Doug Bates and I mentored a SoC student last year, so we know about 
> a lot of the issues.  Unless this year's allocations are done a _lot_ 
> more smoothly, I would recommended sitting this out until a student is 
> definitely allocated.  At that point design work can begin in earnest 
> (and one mistake we made was not being *sure* the student understood 
> the design right at the beginning).  I think it is then that we can 
> help most (in choosing between strategies).
>
> Brian Ripley
>
>
> On Wed, 28 Mar 2007, Leonard Mada wrote:
>
>> Dear Prof. Ripley, dear R-core Team,
>>
>> thank you very much for your kind comments.
>>
>>
>> Prof Brian Ripley wrote:
>>> My guess is that you intended to contact the R core team: I am sorry
>>> that you have had a somewhat unhelpful response from the R-devel list
>>> members.
>>
>> I was indeed unsure which list was best suited for my question. Most
>> responses were nevertheless quite interesting.
>>
>> 1. Cross-Platform
>> Indeed, there may be a problem with the cross-platform requirement, as
>> you pointed out. I had some thoughts on this problem. My feeling is that
>> the code should be split into 2-3 modules: an OOo module
>> (platform-independent), an abstraction layer (platform - DEpendent) and
>> an R module (hopefully as much platform independent as possible). This
>> bears another problem, as there would be now 3 inter-module interfaces.
>> If the R-module (package) has to be platform-dependent, then embedding
>> the abstraction layer into this module seems OK (only 2 modules to deal
>> with). I still believe that the bridge should work on most platforms
>> (but somebody may want to challenge my view).
>>
>> [One of the students came with an idea of using a java-connector, though
>> this surely has to be analysed more thoroughly.]
>>
>>
>> 2. What type of embedding/bridge?
>> I left this question deliberately open. I favour to build in the initial
>> phase something that resembles more closely a GUI to some common
>> statistical functions (there will be definitely another discussion which
>> functions these should be).
>>
>> My hope is too, that later on more advanced features are added, making
>> it a true bridge. While having the ability to read/write .ods files from
>> within R is a sensible alternative for power users, there will be always
>> things that are easier to do in a spreadsheet. Therefore, a real
>> connection will ease the work even for more advanced users.
>>
>> However, if the development of this more powerful bridge needs a very
>> different approach from the simple GUI approach, then starting directly
>> with the more complex code should be analysed more closely. I am still
>> unsure about the right path, especially because I have no understanding
>> of the R internals.
>>
>> 3. Who will do the work?
>> Well, the Google Summer of Code is intended for students: students apply
>> for various projects and those who will be accepted will get paid over
>> the summer by Google. There are various mentors and mentoring
>> organisations, but much of the coding should be done by the students. [I
>> missed R on the Google Sumer of Code list: http://code.google.com/soc/ .
>> While it is unlikely that a student will work on the core, there would
>> be enough alternatives, like writing some packages. I am sure that the
>> listing on the Google site alone will make the program more popular in
>> various other communities.]
>>
>> That said, 2 students showed interest in this project and I hope that
>> they will be accepted (results are still pending).
>>
>> However, I am aware that this will be a tough project and the students
>> will surely need much help. Bridging 2 open-source applications proves
>> (again and again) not to be that simple and expertise from both
>> communities will be invaluable.
>>
>> Independent of the outcome of the Google Summer of Code Initiative, I
>> believe that creating a powerful bridge between R and OOo is essential
>> for the future.
>>
>> There is surely much more to discuss, but I am optimistic that most
>> problems will be solved.
>>
>> Sincerely,
>>
>> Leonard
>>
>> _______________________________________________
>> R-core list: https://stat.ethz.ch/mailman/listinfo/r-core
>>
>