Re: Fwd: GSOC 2014 - Haskell UNO Language Binding

On 03/19/2014 10:44 AM, Tharindu Lakmal wrote:
> I'm Lakmal From University of Moratuwa, Sri Lanka. I like to contribute
> for the topic Haskell UNO Language Binding. I'm looking for a mentor for
> the project.
>
> I read about your description about the project and browsed through many
> details around the topic. I had written a libreoffice plugin a few
> months ago using pyuno. It made me easier to find the details about UNO
> bindings.
>
> I like to get some advice from you about 1 st and third options.
>
> As I got to know,  FFI  doesn't provide direct support for C++, but
> there exist many code generators and methods to do that.
>
> The following links added me another option to call pyuno library
> through Haskell. Better if I can get an opinion on that
>
> http://www.haskell.org/haskellwiki/Cxx_foreign_function_interface
> https://john-millikin.com/articles/ride-the-snake/
>
> By the way I would like to get some opinion about pros and cons of
> option 1(FFI) and 3(Remote Protocol).
>
> I'll prepare the proposal asap and get your feedback also.

Hi Lakmal,

Great to see you interested in this topic.  A few notes:

* Doing a UNO Remote Protocol (URP) bridge might be easier than an FFI 
bridge in that you do that in an external, purely Haskell process (and 
the documentation of URP might be somewhat better than the documentation 
of Binary UNO, which you need to interface with in the FFI case).  In 
the end, a "real" UNO binding would support both, but it would of course 
be fine to concentrate on one of them, at least initially.

* FFI being C rather than C++ should not be a problem, as the Binary UNO 
code that it needs to interact with is just C (although partially 
implemented in C++).  (One UNO concept is the "Binary UNO hub" that 
bridges between different language bindings, which each provide a bridge 
between that language binding and Binary UNO, so if e.g., some C++ code 
calls a UNO method implemented in Java, that call goes via the 
C++-to-Binary-UNO and then via the Binary-UNO-to-JNI bridge.)

* You mention Python, but I wouldn't make a bridge between Haskell and 
PyUNO, but rather between Haskell and Binary UNO.  I see no advantage in 
the former, just more layers of indirection that complicate matters.

* Great to read you already did a LO plugin.  Is the code available 
somewhere to have a look at it?

* To be eligible for LO GSoC, you'd need to do some Easy Hacks first.

* Do you also have experience with Haskell itself?

Stephan