Re: Summer of Code: R and Calc

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.
<kyoshidanovell.com>


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesc.openoffice.org
For additional commands, e-mail: dev-helpsc.openoffice.org