Bridging R to OpenOffice
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