GObject bindings continued...

[Havoc Pennington]

On Wed, 2004-03-17 at 09:51, Mikael Hallendal wrote:
> 
> Essenctially what we want is full introspection of GObjects,
> signals,properties, methods and interfaces?. Currently GObject does
> introspection on signals, properties and implemented interfaces, right?
> 

Yes.

> So to provide introspection of methods the plan is to have a tool to
> parse the header files and produce the introspection XML data from that.

My thought was:
 - scan header file -> XML format
 - XML format -> a file containing a C static variable declaration
   (variable has type DBusGObjectInfo)
 - #include the static variable in the gobject implementation .c file
 - call dbus_g_object_class_install_info() in the class_init function 
   for the gobject

The tool could also support header file -> C static variable directly;
this would be easy to implement if the header file and XML file both
parse to the data structure in dbus-gidl.h, and then there's a converter
from that data structure to either XML or the variable declaration.

In this implementation, it's also possible to write the XML directly
rather than using the magic C header scanner.

DBusGObjectInfo's current definition may be crackrock. One goal there
should be to minimize the number of symbols seen by the linker and
minimize the size of the data overall. Qt 4 puts all the moc metadata
for an object in two huge strings for this reason, so they only have two
symbols in the .o file.

> Since the header files for C/C++ lack all the information needed to
> produce this data what is the plan (and how is it done in QT?). Is it
> done by marking up the header files with special comments that are used
> to no whether a method argument is an in/out argument and such?

My thought (and essentially what Qt does) is to just figure it out from
the C, and programmers just have to write C that the tool understands. 
Then magic comments can annotate/correct. Pretty much exactly the way we
do language bindings and gtk-doc today.

For example, if a method takes a struct argument then the tool will
complain and bail out. If it takes "const char*" then that's "in string"
and if it takes "char **" then that's "out string"

For signals, I was thinking you'd have to mark them with a comment like 
/*< remote */ for them to be exported on the bus, otherwise it's too
inefficient.

For methods, maybe they export by default, and can be exempted with
/*< noremote */

Methods are required to follow the GObject conventions for naming and
first argument as the object, or they won't be included in the
introspection data.

If someone doesn't want to follow the conventions or wants to make their
C formatting all weird and hard to parse, then they can write the XML
file. ;-)

I think it's fine to have a limited parser that pukes on lots of legal
C, as long as it gives decent error messages when it pukes, and works on
the typically-formatted headers in GNOME.

> Adding full introspection to the GObject layer sounds like something we
> want anyway since it would help when binding it to other languages since
> from what I can see all bindings effort duplicate these efforts of
> tagging up method calls arguments for in/out etc.       
> 
> Does anyone know how interested GObject maintainers would be to add this
> to GObject itself so we don't have to maintain this in D-BUS?

I haven't proposed it, though it might be sort of nice.

> Also, what is the plan of more complex data types such as structs as
> arguments, should the be passed as data over D-BUS to remote calls or
> passed as a reference to a remote "object"?

I'd say structs are definitely data and not objects. Generally speaking
you can't remote-export or introspect methods that take struct/object
args, I would say. Too hard.

One punt solution would be to allow an annotation comment mapping the
struct arg to a custom type name.

Of course if you did a generic GObject introspection feature rather than
a D-BUS specific one, you'd want to support any registered GType as an
argument, including objects. But then when registering the object with
D-BUS some methods may be too complex to export remotely.

Havoc