IDL language

[David Zeuthen]

On Sat, 2009-05-09 at 00:56 -0400, Havoc Pennington wrote:
> Yeah, I find that named structures are more pain than gain... I'd tend
> to almost always use a dictionary instead, and something hash-like in
> C/C++ is not that bad. The main reason to use a structure instead of a
> dictionary is when you are just shoveling big hunks of data, like an
> array of points. But in those cases, I don't know - I don't like
> having "IPC" types leak all over an app, that was certainly a mess in
> CORBA, and I'd tend to hand-code a struct and manually convert the IPC
> stuff into it. Or tend to want GdkRectangle or QRect, not "struct
> orgFreedesktopRectangle" or something.

FWIW, I think such simple structs (akin to blittable types in .NET)
would just be represented as Plain Old Structs by C and C++ code
generators, e.g. the GLib code generator I'm working on would generate

 typedef struct {
   gint x;
   gint y;
   gint width;
   gint height;
 } OrgExampleRectangle;

which is structural identical to GdkRectangle. Heck, we should probably
have command-line options to actually request that org.example.Rectangle
should be mapped to GdkRectangle at code generation time. And similar
things.

It's only when a struct contains members that are allocated that we get
into problems (and these structs in GLib would be based on GObject so it
would be possible to hook a destructor and serialization interfaces onto
them).

> > Making the IDL compiler both read and write these socalled typelibs
> > sounds useful too; I'll send some mail when it can do that. Then we can
> > iterate over what kind of additions I made, we want in the spec. Unless,
> > that is, you are already opposed to the already suggested additions
> > (that would be struct, dynamic_struct, enum, error_domain)?
> 
> I'm not a fan / don't really get the aspect of dynamic_struct where
> the struct name is included in what's sent over the wire.

I'll change dynamic_struct to just be a{sv} - Simon already made a
convincing point about that elsewhere in the thread. Sure, throwing away
the name (e.g. going from (sa{sv}) to a{sv}) means it's going to be a
little harder handling

 GetStuff (variant value);

where @value is a a{sv} that can either be AtaSmart or ScsiData which
are both declared as dynamic_struct / using @ArgTypeHints (this was the
intent for including the name). I guess that C programmers will have to
live with that. On the upside it won't screw over gjs programmers and it
is backwards compatible.

> These things are mostly not in the common spec because nobody's ever
> really wrestled the discussion to the ground and written up the spec
> patches. (For that matter, I don't even remember if the XML format is
> really specified...)

OK, I'll look into proposing some additions once I have something
concrete.

The working assumptions that I'm using here, are

 - akin to <interface> we will have <struct> and <error_domain> and
   <enum> tags (and also other stuff they contain)

   - I will refer to these as types in the following

 - the typelib will have exactly one file per interface/struct/enum/
   error_domain declaration. This means that e.g. an interface and
   a struct can never share the same name. Also means these are in
   different files.

 - a file in the typelib declares exactly one type and one type only

 - the name of the file MUST match the type that is being declared (it
   will only have .xml appended to it)

 - we will introduce something like a @org.freedesktop.DBus.DocString
   annotation

 - the typelib lives in /usr/share/dbus-1/typelib and is just a flat
   directory with a bunch of conforming files

Does these assumption sound good?

Open questions

 - do we want a dbus-typelib-install(1) command that validates these
   assumptions? Might be useful to also make it yell about warnings
   such as missing docs etc.

   (generally, if you are installing stuff into the typelib, you do this
    only because you expose a public interface. So I think it's nice
    to yell at people that some things are not documented.)

 - should we use a separate DOCTYPE / DTD than

    <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
     "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">

   for example

    <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Type Library 1.0//EN"
     "http://www.freedesktop.org/standards/dbus/1.0/typelib.dtd">

   I don't know.

    David