[Libreoffice] minor idl fixes

[Tomas Hlavaty]

Hi Stephan,

Stephan Bergmann <sbergman at redhat.com> writes:

> Historically, the situation is as follows:

thanks a lot!

> At runtime, the C++ UNO binding queries the types.rdb for certain data
> (e.g., when (un-)packing data as ANY).

OK.  Does it need to go through the rdb file?  It could as well be
already compiled into a dll.

> class files from it. (It does not go via .java source files so it
> could simultaneously support Java 4 and new Java 5 features at a time
> when that was still relevant.)

I see.

> Binding UNO to dynamic languages like Python takes another approach.
> It obtains any necessary information purely at runtime, from the
> types.rdb, via UNO services that make available that information.  It
> does not require any *maker tool to generate language-specific
> artefacts from the complete type information upfront.

OK.  But it could be made faster if the type information was available
in one go instead of querying per instance, if the speed was a problem?
So we could have the type information in a readable format or generated
as a py file.  Or maybe everybody is happy with the way python does it?

What about StarBasic?  I guess that would be similar to Python.

> My point of view is to replace the binary .rdb format with a simpler,
> most likely textual format (for which easy reading can be implemented
> in any language, if need be).  One viable approach seems to be to
> streamline the current .idl file format and directly use that syntax
> for any new-style ".rdb" files (catenating together the individual
> .idl files into a large .rdb file, say).

Agree.  This is what I did in the unoidl2 project I mentioned in
previous emails.

> Another point to re-evaluate is how much of that complete type
> information to duplicate in the artefacts generated for the various
> language bindings.

Why not all?  It's not that much.

> On the one hand, it might be advantageous to encode more information
> in the generated C++ artefacts (potentially even generating a
> dedicated dynamic library containing the relevant, instead of
> spreading it inlined across header files, where the linker can
> recombine part of it again). That could help ensure that the
> (new-style) types.rdb need not be read early on during startup (so if
> loading it where somewhat costly that would not be that much of a
> problem as it is today).

Yes.  But wouldn't be the type database still required as C++ doesn't
have the reflection capability built-in?

> On the other hand, an easily parsable format would allow Java to
> reduce the amount of information currently stored in generated .class
> files, and instead rely on the complete type information available as
> a (new-style) types.rdb.  Java .class files could even be generated on
> the fly from the types.rdb information using a dedicated Java class
> loader. (That would remove the ugly requirement that .oxt extensions
> need to bring their additional UNO types as both .rdb and .class
> files.)

Here I don't know how these .oxt extensions work.

Is the size of generated .class files an issue?

  3680 2011-01-26 23:31 java/openoffice/unoloader.jar
108139 2011-01-26 23:31 java/openoffice/jurt.jar
  4207 2011-01-26 23:33 java/openoffice/java_uno.jar
 55519 2011-01-26 23:35 java/openoffice/juh.jar
258511 2011-01-26 23:31 java/openoffice/ridl.jar
448964 2009-11-23 23:38 java/gnome-java-bridge.jar
  
Those jar files seem reasonably small.

>> LO projects like registry, rdbmaker, regview, regmerge, idl, idlc,
>> climaker, javamaker, codemaker would be deprecated.
>
> Though idlc, climaker, javamaker, codemaker would "just" be replaced
> with your new code (that conceptually does the same thing), if I get
> you right?

Exactly;-)

> (Note that module idl is completely unrelated to UNO.)

What is it then?  It looks like something related to idl compilation.

> As Micheal already pointed out, changes to the .rdb format would best
> be kept behind the existing interfaces abstracting from it, so that
> those "client" modules would hardly notice.

Great if that's the case.

>> Do we have a better documentation on type mappings then for example
>> <http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Type_Mappings>?
>
> For Java I once detailed that at
> <http://wiki.services.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping>
> (and the UNO type system itself at
> <http://udk.openoffice.org/common/man/typesystem.html>).

Thank you for the links!

Cheers,

Tomas