Re: [Libreoffice] minor idl fixes

Hi Michael,

>       Nice work - thanks :-) It'd be great if you could give an explicit
> licensing statement for your contributions; something like:
>
>       "All my contributions to LibreOffice are licensed under
>        the MPL/LGPLv3+ dual license"
>
>       or somesuch :-) then we can add you to:
>
>       http://wiki.documentfoundation.org/Development/Developers
>
>       Which helps smooth the flow. Anyhow - great to have you contributing

I would be happy with LGPLv3+ but I haven't found much on why was MPL
added and/or preffered for new contributions.  Could you please point me
to some discussions so I can make up my mind on this matter?

> is there any particular piece you'd like to work on ? or annoying bug
> you'd like to fix ? :-)

There seems to be agreement that the RDB type database should go away.
There are several LO projects that would be affected by this and they
seem rather complex with dependencies.  Also, for example the conversion
from uno idl to java and cli goes directly to the binary format (class
file, assembly) and it's hard to see what they actually generate.

As a proof of concept, I have created a unoidl2 project:

   git clone http://logand.com/git/unoidl2.git

Note that it doesn't work yet but already has the parsing part in place,
i.e. can generate ast and has an incomplete unoidl2java generation.

The idea is that there would be a collection of small programs that
would convert uno idl files to different languages, e.g. unoidl2java,
unoidl2cs, unoidl2vala, unoidl2xml, unoidl2py etc.  These programs
should be as simple as possible with no dependencies so that anybody can
write a new uno idl converter for his programming language easily.

This would allow us to get rid of the RDB files (although I need to
familiarise myself with current use-cases to understand the impact of
such change, e.g. merging in custom plugins).

LO projects like registry, rdbmaker, regview, regmerge, idl, idlc,
climaker, javamaker, codemaker would be deprecated.

It would also work with text files only (and the results could be
commited into the repository for easier inspection of changes).
Conversion to java class files and .NET assemblies would be delegated to
dedicated compilers (javac, csc).

The other affected LO projects would likely be:

- binaryurp
- bridges
- cli_ure
- cppu
- cppuhelper
- javaunohelper
- pyuno (native?)
- ridljar
- scripting
- unodevtools
- unoil

although there is little information on what some projects are supposed
to do and how people use them.

Do we have a better documentation on type mappings then for example
<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Type_Mappings>?

It might be interesting to generate vapi file for vala programming
language, for example.  Are there any examples of connection to
libreoffice from plain C?

Thank you,

Tomas