On Sat, 2007-04-07 at 22:25 -0400, Wojciech Gryc wrote: > Thanks for the input on GPL issues. Is creating an external add-on to > OpenOffice an option? I'm thinking of creating a package that isn't > distributed with OO itself, but one can download it (R executable included) > and install it themselves.
I will defer the final call to Niklas, or someone else who makes a decision of this nature. But my own thinking is that, if we list this task as a GSoC task, then it's a functionality that we want to ship with the main product, not just an add-on that can be downloaded separately. But I welcome input from others on this. > > Also, thanks for bringing the C++ option up. It's something I didn't > consider only because of my experience with using other packages, but after > reading the guide and doing some general searching, I think this would be a > good way to go (or at least to research in more depth). I'm just finishing > up some final projects for school this weekend, so I haven't been able to do > as much exploring as I'd like, but hope to do so next week. Excellent. :-) > With regards to the Java or Python implementations, I definitely understand > the time penalty for launching the software, but am not so sure about the > rest. While it does add an extra layer in terms of connections, my > understanding is that once you send the data to R through JRI or RPy, it > does all the calculations externally and just sends output back, so I don't > know how slow it would be during use. I'm happy to read up on this, and > would welcome your thoughts. Yes, you are correct about this; as long as our code provides just the connectivity between the R library and OO.o, run-time performance loss will be minimal, because all the numerically intensive functions are implemented in native code (R's core). So, there should not be any issue in using Python or Java for connectivity (aside from the startup time). BTW, has anybody checked the license of these frameworks? The concern I wanted to raise was that, when/if our code grows beyond just providing such a simple connection layer, and start implementing functionality that the Java/Python framework doesn't have, then we may eventually hit a performance issue that might necessitate re-writing it in C/C++, wholly or partially. This may or may not happen depending on the scope of this task, but it is not uncommon for a project that started simple to grow larger later on. But note that this is just a concern coming from my own experience with other projects, so this may not necessarily apply to this task. I just wanted to mention it so that we are all aware of that possibility. Hope this clarifies the intent of my last post. :-) Kohei -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
